Why does an Angular TestBed test fail on an error the running app would only log, and what does rethrowApplicationErrors control?

## What an application does with caught errors Angular catches some errors on your behalf rather than letting them escape to the browser: - errors thrown while change detection runs, inside `ApplicationRef.tick()` — a template expression that throws, a lifecycle hook that fails; - errors thrown by template event listeners, such as a `(click)` handler. It forwards them to the application's **`ErrorHandler`**. The default `ErrorHandler` logs to the console, and the application keeps running. In production that is often right: one broken widget should not take down the page. In a test it is dangerous. A component whose template throws on every check would render nothing, log an error, and — if nothing asserted on the missing text — pass. ## What TestBed does instead TestBed replaces the internal error path with its own handler: 1. It calls **your** `ErrorHandler` first (the one the testing module resolves, so a custom handler you provide still sees the error; if that handler itself throws, its error is used instead). 2. If any `fixture.whenStable()` promises are **pending**, it **rejects** them with the error. 3. Otherwise it **rethrows** the error, so it fails the test. The behaviour arrived in steps; the version matters when an upgrade suddenly turns green suites red: | Version | Change | |---|---| | v19 | Errors thrown during `ApplicationRef.tick` are rethrown in TestBed | | v20 | Uncaught errors in event listeners are also reported and rethrown | | v21 | Adding `provideZoneChangeDetection()` to TestBed providers no longer prevents the rethrow | ## The option `rethrowApplicationErrors` is a field of `TestModuleMetadata`, so it is set **per test** through `configureTestingModule`: ```ts TestBed.configureTestingModule({ imports: [StatusTicker], rethrowApplicationErrors: false, // last resort }); ``` - **Default: `true`.** - `false` means errors only go to `ErrorHandler`, which by default just logs them. - It is not one of the `initTestEnvironment` options, so it cannot be switched off suite-wide there; each test that needs it says so. The Angular changelog and error-handling guide describe `false` as a **last resort**, for the rare test that deliberately checks the application survives an error. ## Better options than turning it off **Fix the setup.** Most newly surfaced errors are real: a missing provider, an input the template assumes is set, a fake returning `undefined` where the template reads a property. The rethrow found a bug in the test or the component. **Assert the error when it is the point of the test.** Two patterns come straight from the changelog: - Trigger change detection synchronously and expect it to throw: `expect(() => TestBed.inject(ApplicationRef).tick()).toThrow()`. - Expect a pending stability promise to reject: with a pending `fixture.whenStable()`, TestBed rejects it with the error instead of throwing. **Test the handler, not the swallowing.** If the requirement is "errors are reported to our monitoring", provide a fake `ErrorHandler` and assert it was called. TestBed calls it before rethrowing, so the assertion still works — then catch or expect the rethrown error. ## A worked example A status ticker's template reads `status()!.label`, and its `status` signal starts as `undefined`. A test that wants to prove such failures reach monitoring, without switching the option off, can: 1. provide a recording `ErrorHandler` (an object whose `handleError` pushes into an array) in `configureTestingModule`; 2. create the component — in a zoneless test, the default since v21, a new fixture is attached for automatic change detection; 3. run change detection synchronously inside an assertion that expects a throw, `expect(() => TestBed.inject(ApplicationRef).tick()).toThrow()`, the pattern the v19 changelog gives; 4. assert that the recorder received the error. The recording handler sees the error first, TestBed then rethrows it out of `tick()`, and the test asserts both. ## How it relates to other TestBed error options - `errorOnUnknownElements` / `errorOnUnknownProperties` control whether template **compilation** problems — unknown elements and bindings — throw or only log. TestBed's own default is `false`; the CLI's Vitest setup initialises the environment with both set to `true`. - `teardown.rethrowErrors` controls errors thrown during **cleanup** after a test. - `rethrowApplicationErrors` controls errors caught while the app **runs** — change detection and listeners. Keeping all three strict is what stops a test suite from passing over broken components.