In Angular, when can you unit-test a service with a plain new instead of TestBed, and how do you swap its dependencies for doubles?

## Two ways to get a service under test A **service** in Angular is a class whose instance is created and handed out by **dependency injection (DI)**. To unit-test one you need an instance plus control over its **dependencies**, the other services it asks for. There are two ways to get that. - **Plain construction**: `new UserProfileStore(fakeApi)`. No Angular machinery; the test passes collaborators in by hand. - **TestBed**: `TestBed.configureTestingModule({ providers: [...] })` builds a test injector, and `TestBed.inject(UserProfileStore)` asks it for the instance, exactly as the application would. ## When plain `new` works, and when it cannot Plain construction works when the class receives everything through **constructor parameters**, or has no dependencies at all. The test is then an ordinary object test: fast, no configuration, fully explicit. It stops working when the class calls **`inject()`**, the default style for new Angular code: - `inject()` in a field initializer or constructor body needs an **injection context**. Called from a bare `new`, it throws **NG0203** ("`inject()` must be called from an injection context"). - APIs built on top of `inject()` need one too, unless you hand them an injector or `DestroyRef` explicitly: `effect()`, `toSignal()`, and `takeUntilDestroyed()` without an argument. `TestBed.runInInjectionContext(() => new UserProfileStore())` is a middle path: the constructor runs inside TestBed's environment injector, so `inject()` resolves from the providers you configured. Most teams simply use `TestBed.inject()`, which builds the instance inside that injector and returns the same instance to every later request in the test. ## Swapping a dependency with providers The **provider** is the seam. In `configureTestingModule`, a provider for the dependency's token replaces the real one for this test's injector: | Provider form | What the service receives | Typical use | |---|---|---| | `{ provide: UserProfileApi, useValue: fake }` | the object you built | a small hand-written fake or a runner spy object | | `{ provide: UserProfileApi, useClass: FakeUserProfileApi }` | a new instance of the fake class | a reusable fake with its own logic | | no provider | the real `UserProfileApi` | when the real one is cheap and deterministic | Points that matter in interviews: 1. A service marked `@Injectable({ providedIn: 'root' })`, or `@Service()` since v22, needs **no provider entry** to be injectable in tests; a test-module provider for the same token **overrides** the root one. 2. A class with plain `@Injectable()` (no `providedIn`), or `@Service({ autoProvided: false })`, **must** be listed, or `TestBed.inject` fails with **NG0201** ("No provider found"). 3. Type the fake against the real class (`Pick<UserProfileApi, 'load'>` or a full implementation) so a renamed method breaks the test at compile time. 4. Fake only what the unit touches. Replacing every collaborator turns the test into a check of your own fakes. 5. TestBed is reset between tests, so each spec configures its own providers and gets fresh instances. ## What kind of double to hand in The provider decides *where* the double goes; the double itself can take several shapes: - A **stub** returns fixed values (`load` always resolves to the same profile). It controls the input to the unit under test. - A **fake** is a small working implementation, such as an in-memory map of profiles. It suits tests that make several calls and expect consistent state. - A **spy** records calls so the test can assert that the service asked for profile `42` exactly once. Spy helpers come from the test runner, not from Angular, so the syntax differs between runners; the provider wiring does not. Whatever the shape, assert on the **service's observable behaviour** first (the signal it exposes, the value it returns) and on interactions only when the interaction is itself the requirement, for example "does not call the API twice for the same id". ## Choosing between them - Use **plain `new`** for pure logic classes and constructor-injected services where speed and explicitness matter. - Use **TestBed** for anything that uses `inject()`, signals with effects, `DestroyRef`, or `HttpClient`; it is also the only option when the service must see the same provider graph as the app. - Do **not** refactor a service back to constructor injection only to avoid TestBed. `inject()` is the recommended style, and TestBed setup for a service is a few lines. One trap belongs to TestBed's override API rather than to this topic: a dependency provided in a **component's** own `providers` array is not replaced by a module-level provider, because the component's injector sits closer to the consumer. Overriding it uses TestBed's override methods.