mengw15 commented on code in PR #5037:
URL: https://github.com/apache/texera/pull/5037#discussion_r3250041640


##########
frontend/src/app/workspace/component/workspace.component.spec.ts:
##########
@@ -359,4 +368,23 @@ describe("WorkspaceComponent", () => {
       expect(component.copilotEnabled).toBe(false);
     });
   });
+
+  // Exercises the rendered template: the `<ng-template #codeEditor>` outlet is
+  // present, so the @ViewChild query resolves to a live ViewContainerRef and
+  // ngAfterViewInit can publish it to CodeEditorService.
+  describe("child rendering side effects", () => {
+    it("publishes the resolved ViewContainerRef to CodeEditorService.vc on 
view init", async () => {
+      await createFixture();
+      // Before view init nothing has been assigned. (The pre-fixture stub on
+      // codeEditorViewRef in createFixture only protects ngOnDestroy teardown
+      // — the service.vc should still be untouched.)
+      expect(codeEditorService.vc).toBeUndefined();

Review Comment:
   Minor: this assertion relies on `CodeEditorService.vc` being `undefined` at 
the start of the test, which depends on TestBed rebuilding the injector between 
specs. That's the current behavior, but if the service ever becomes a 
longer-lived singleton (or test isolation config changes), this will start 
failing in ways that are hard to reproduce.
   
   Consider making the starting state explicit so the test doesn't carry an 
implicit ordering dependency:
   
   ```ts
   codeEditorService.vc = undefined as any;
   await createFixture();
   fixture.detectChanges();
   expect(codeEditorService.vc).toBe(component.codeEditorViewRef);
   expect(typeof codeEditorService.vc.createEmbeddedView).toBe("function");
   ```
   
   Same outcome, no hidden DI assumption.



-- 
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]

Reply via email to