Challenge 2: Why TestBed Needs More Ceremony — Possible Solution
====================================================================

Angular's component architecture is built around DEPENDENCY INJECTION
— a component typically declares its dependencies (services, other
injectable providers) as constructor parameters, and relies on
Angular's own injector to actually supply real (or, in tests, fake)
implementations of them at the moment the component is instantiated.
This is the same DI concept the site's own Angular course covers as a
core architectural feature, not an incidental detail.

Because of this, a component genuinely CANNOT be instantiated in
isolation the way a React function component (which just receives
plain props) or a Svelte component can — Angular needs to know, ahead
of time, what module context the component belongs to and what its
dependencies should resolve to. TestBed.configureTestingModule({...})
exists specifically to set up that context: declaring the component,
and (in more realistic tests) providing mock versions of whatever
services it depends on, before TestBed.createComponent() can actually
produce a working instance.

fixture.detectChanges() is a separate, additional piece of ceremony
for a different reason: Angular's change detection (deciding when to
re-render based on data changes) normally runs automatically as part
of the framework's own zone-based scheduling in a real running app,
but that automatic triggering doesn't happen in the synchronous,
isolated context of a test — so a test has to trigger it explicitly.

IN SHORT: the extra ceremony is a direct, necessary consequence of two
genuine Angular architectural features (DI-driven instantiation and
zone-based change detection) that React, Vue, and Svelte simply don't
have in the same form — not an accident of Angular's testing tools
being worse-designed, and not a sign that Angular's underlying testing
PHILOSOPHY differs from the other three frameworks.