Copilot commented on code in PR #7304:
URL: https://github.com/apache/texera/pull/7304#discussion_r3709701929
##########
frontend/src/app/workspace/component/codearea-custom-template/codearea-custom-template.component.spec.ts:
##########
@@ -52,4 +55,110 @@ describe("CodeareaCustomTemplateComponent", () => {
it("should create", () => {
expect(component).toBeTruthy();
});
+
+ /**
+ * The component's whole job is to keep one shared, per-operator "is the
editor open" flag in
+ * sync across three inputs: this component's own open/close, the same
operator's editor opened
+ * by a co-editor, and the component being torn down while the editor is
still up. The flag lives
+ * in CodeEditorService keyed by operator id, so a mix-up there silently
reopens (or fails to
+ * reopen) the wrong operator's editor.
+ *
+ * `openEditor` is driven directly rather than through the template button:
it calls
+ * `codeEditorService.vc.createComponent`, and `vc` is a ViewContainerRef
the real workspace
+ * supplies. The tests below install a fake one so the component's own
bookkeeping is observable
+ * without standing up a Monaco editor.
+ */
+ describe("editor-open state", () => {
+ let codeEditorService: CodeEditorService;
+ let destroyCallbacks: (() => void)[];
+
+ // The highlighted operator is what getOperatorID reads, and it is the key
every
+ // setEditorState/getEditorState call is scoped by.
+ function highlightedOperatorId(): string {
+ return
TestBed.inject(WorkflowActionService).getJointGraphWrapper().getCurrentHighlightedOperatorIDs()[0];
+ }
+
+ beforeEach(() => {
+ codeEditorService = TestBed.inject(CodeEditorService);
+ destroyCallbacks = [];
+ // Stand-in for the workspace's ViewContainerRef. Records the onDestroy
hook the component
+ // registers so the close path can be triggered without a real component
teardown.
+ codeEditorService.vc = {
+ createComponent: () => ({
+ instance: {} as any,
+ onDestroy: (cb: () => void) => destroyCallbacks.push(cb),
+ destroy: () => destroyCallbacks.forEach(cb => cb()),
+ }),
+ } as any;
+ });
Review Comment:
The tests derive the operator id from
WorkflowActionService.getJointGraphWrapper().getCurrentHighlightedOperatorIDs()[0],
but in this spec the JointGraphWrapper starts with an empty
highlighted-operators list. That makes `highlightedOperatorId()` (and the
component’s private `operatorID`) effectively `undefined`, so these assertions
end up exercising CodeEditorService state under an `undefined` key and can pass
without actually validating the per-operator behavior described in the comment.
Consider stubbing `getCurrentHighlightedOperatorIDs()` to return a
deterministic operator id and re-running `ngOnInit()` in this suite so
`operatorID` is non-empty and the tests truly validate per-operator scoping.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
