Testing Components with Signals

Reading a signal input or internal signal from a test is straightforward — call it as a function, exactly as you would in application code (fixture.componentInstance.count()), and setting a writable signal directly on the component instance for test setup works the same way (fixture.componentInstance.count.set(5)). The more interesting nuance is around signal inputs specifically: because input()/input.required() are meant to be set by Angular's own binding mechanism, directly assigning a value to a signal input property from a test doesn't work the way it did for a plain decorator-based @Input() — instead, Angular's testing utilities provide fixture.componentRef.setInput('inputName', value), which is the correct, supported way to simulate a parent setting a signal input's value in a test.

Another subtlety: because signal changes propagate synchronously through the reactivity graph but the DOM still only updates on the next change detection pass, you generally still need fixture.detectChanges() after changing a signal's value in a test before asserting against the rendered DOM — Signals don't eliminate the need to trigger Angular's test-harness change detection manually, they just changed how the underlying dependency tracking works.

A solid interview answer also notes that computed() and effect() are just as testable as any other logic — a computed() signal can be read directly and asserted against without any component or TestBed involvement at all if it's defined as a standalone function outside a component class, which is actually a testability advantage Signals offer for state logic that doesn't strictly need to live inside a component.