angular-testing-patterns

name	angular-testing-patterns
description	Guides expert-level angular testing patterns implementation: typescript and testing decision frameworks, production-ready patterns, and concrete templates for angular testing patterns workflows. Use when the user asks about angular testing patterns, angular testing patterns configuration, or typescript best practices for angular projects. Do NOT use when the user needs a different web development capability -- check sibling skills in the web development subcategory.
license	Apache-2.0
metadata	{"author":"foundry-skills","version":"1.0.0","tags":"typescript testing frameworks automation","category":"web-development","subcategory":"web-development","depends":"","disclaimer":"none","difficulty":"intermediate"}

Angular Testing Patterns

When to Use

Use this skill when:

• User is writing unit tests for Angular components, services, directives, pipes, or guards using TestBed and Jasmine/Jest
• User needs to test Angular components with complex template bindings, @Input/@Output properties, or child component interactions
• User is setting up a testing strategy for an Angular project and needs to decide between shallow rendering, isolated tests, and integration tests
• User wants to test Angular services that use HttpClient, RxJS observables, signals, or complex dependency injection hierarchies
• User needs to configure Jest as a replacement for the default Karma/Jasmine setup in an Angular project
• User is testing NgRx store interactions, effects, selectors, or reducers in an Angular application
• User needs to debug flaky tests, slow test suites, or tests that fail only in CI but pass locally
• User is testing Angular Router navigation, route guards, or resolver logic
• User wants to implement component harnesses using Angular CDK Testing infrastructure

Do NOT use this skill when:

• User needs help with React Testing Library or Vue Test Utils -- check the react-testing or vue-testing skills
• User asks about end-to-end testing with Cypress or Playwright for Angular apps -- check the e2e-testing skill
• User needs help with Angular application architecture or state management design outside of testability concerns
• User is asking about testing Node.js backends, REST APIs, or non-Angular TypeScript code -- check the node-testing skill
• User needs help with CI/CD pipeline configuration beyond test runner execution -- check the ci-cd-pipelines skill
• User is asking about general TypeScript type system usage not related to tests -- check the typescript-patterns skill
• User needs help with Angular performance profiling or bundle analysis -- check the angular-performance skill

---

Process

1. Classify the Code Under Test and Choose the Right Test Type

Before writing a single line of test code, identify exactly what you are testing and which test strategy applies. Angular has four distinct testing contexts that require fundamentally different setups.

• Isolated unit tests -- for pure logic: services with no HTTP, pipes, utility functions, pure reducers. Use no Angular testing module at all. Instantiate directly with new MyService(dep1, dep2) and pass mocked dependencies manually.
• Shallow component tests -- for components where only this component's behavior matters. Use NO_ERRORS_SCHEMA or CUSTOM_ELEMENTS_SCHEMA to suppress child component errors, or declare stub components. This is the most common pattern.
• Deep integration tests -- for testing parent/child component interaction, content projection, or template-driven forms. Declare all child components explicitly. Reserve this for true integration concerns -- it is expensive.
• TestBed service tests -- for services with Angular DI dependencies like HttpClient, Router, or store providers. Use TestBed.configureTestingModule with real or stubbed providers.

Identify the classification before writing the describe block. Wrong classification is the #1 source of brittle, slow, or falsely-passing tests in Angular projects.

2. Configure TestBed with Minimal, Targeted Declarations

TestBed configuration directly controls test speed and isolation. Every unnecessary declaration adds compilation overhead.

• Import only the modules your component actually needs. Replace BrowserModule imports with CommonModule in tests. Never import AppModule or CoreModule -- these pull in the entire application.
• Use TestBed.configureTestingModule with declarations, imports, providers, and optionally schemas.
• For components using Angular Material, import individual component modules (e.g., MatButtonModule, MatInputModule) rather than MaterialModule barrel imports.
• Prefer ComponentFixture<T> over manually constructing components. Let TestBed handle change detection lifecycle.
• Use compileComponents() only when your component has external template URLs or style URLs. Inline templates skip this requirement and speed up the test suite.
• When using Jest instead of Karma, configure jest-preset-angular in jest.config.ts. Set testEnvironment: 'jsdom', enable inlineStylesTransformer, and set tsconfig to your tsconfig.spec.json.
• Set teardown: { destroyAfterEach: true } in TestBed.configureTestingModule for Angular 14+ projects to prevent state leaking between tests.

3. Mock Dependencies at the Right Fidelity Level

Overmocking produces tests that pass but do not catch real regressions. Undermocking produces slow, brittle tests that couple to implementation.

• For services injected into components, use jasmine.createSpyObj or Jest's jest.fn() to create typed spies: const serviceSpy = jasmine.createSpyObj<MyService>('MyService', ['getData', 'saveItem']).
• For HttpClient, use HttpClientTestingModule and HttpTestingController rather than mocking HttpClient directly. This lets you assert on request URLs, methods, headers, and bodies.
• For Router, provide RouterTestingModule for most navigation tests. For guard tests, mock ActivatedRouteSnapshot and RouterStateSnapshot directly with object literals.
• For RxJS observables in services, return controlled Subject, BehaviorSubject, or of(value) from spy return values. Never use interval or timer in tests without fake async.
• For NgRx, use provideMockStore from @ngrx/store/testing with initialState. Do not configure a real store reducer in unit tests.
• For Angular Signals, signals are synchronous and do not need special treatment, but you must call fixture.detectChanges() after mutating signal values to trigger template re-rendering.
• Typed mocks using Partial<T> cast as T are acceptable for simple cases: { getData: () => of(mockData) } as MyService.

4. Control Change Detection Deliberately

Uncontrolled change detection is the second leading cause of flaky Angular tests. Understanding when Angular's CD runs in tests versus production is critical.

• fixture.detectChanges() manually triggers Angular's change detection cycle. Call it once after setup to render the initial state, then again after each interaction that should update the view.
• Never rely on automatic change detection in ComponentFixture unless you explicitly set { detectChanges: false } in createComponent options to understand when you are overriding defaults.
• Use fixture.autoDetectChanges(true) only in integration tests where you want CD to fire on every async completion. It adds overhead and obscures the exact trigger of a view update.
• For async operations (promises, observables, HTTP), wrap the test body in fakeAsync and use tick(ms) to advance the virtual clock. Use flushMicrotasks() for resolved promises.
• Use waitForAsync (formerly async) when you have actual async/await patterns or need the real zone. Prefer fakeAsync because it gives you deterministic time control.
• After calling tick() or advancing time, always call fixture.detectChanges() to flush the view.
• For debounceTime(300) in a component, the test must call tick(300) inside fakeAsync to simulate the debounce, then detectChanges().

5. Query the DOM Accurately and Resiliently

How you query the DOM determines whether your tests survive template refactors. Fragile selectors are a maintenance tax.

• Prefer By.css('[data-testid="submit-button"]') over By.css('.btn-primary') or By.css('button:nth-child(2)'). Add data-testid attributes in templates specifically for testing. This decouples tests from CSS styling decisions.
• Use fixture.debugElement.query(By.css(...)) to return a DebugElement. Call .nativeElement to get the DOM node and .componentInstance to get the component instance.
• Use fixture.debugElement.queryAll(By.css(...)) when asserting on lists of items (e.g., *ngFor rendered items).
• Use By.directive(MyDirective) to find elements that have a specific directive applied.
• For Angular CDK-based components (Material), use HarnessLoader from @angular/cdk/testing/testbed and component harnesses. Example: await loader.getHarness(MatInputHarness) returns a high-level interface that survives internal Material DOM changes.
• Text content assertions: use nativeElement.textContent.trim() rather than innerHTML to avoid whitespace and comment node noise.
• Trigger DOM events with nativeElement.dispatchEvent(new Event('click')) or triggerEventHandler('click', null) on the DebugElement. Use nativeElement.click() for simple click triggers.

6. Test Asynchronous Code Patterns Correctly

Async testing is where most Angular test failures and flakiness originate. Each async pattern has a specific correct handling strategy.

• HTTP requests with HttpTestingController:

  const req = httpMock.expectOne('/api/users');
  expect(req.request.method).toBe('GET');
  req.flush(mockUsers);
  httpMock.verify(); // in afterEach
  

• RxJS observables with fakeAsync:

  fakeAsync(() => {
    let result: User[];
    service.getUsers().subscribe(data => result = data);
    tick();
    expect(result).toEqual(mockUsers);
  })
  

• Debounce/throttle operators: Use tick(debounceMs + 1) to advance past the debounce threshold. Always add 1ms buffer.
• Intervals and polling: Use discardPeriodicTasks() at the end of fakeAsync blocks that start intervals, or the test will throw "1 periodic timer(s) still in the queue".
• Angular animations: Import NoopAnimationsModule instead of BrowserAnimationsModule in all test modules. This disables animation timers that would require fakeAsync tick management.
• Resolvers and lazy-loaded routes: Test these with RouterTestingModule.withRoutes([]) and router.navigate() calls inside fakeAsync/tick blocks, then assert on router.url.
• Signals-based async (Angular 17+): Computed signals and effects are synchronous, but effect() runs after change detection. Use TestBed.flushEffects() to force pending effects to execute.

7. Structure Tests for Readability and Maintainability

Test structure governs how quickly a developer can diagnose a failing test six months after writing it.

• Follow the Arrange-Act-Assert (AAA) pattern explicitly within each it block. Consider adding a blank line between each phase for visual clarity.
• Use nested describe blocks to group tests by behavior or state: describe('when user is not authenticated', ...) and describe('when form is valid', ...). Limit nesting to 3 levels maximum.
• Use beforeEach for common setup shared across an entire describe group. Never use beforeAll for Angular TestBed setup -- it causes component state to leak between tests.
• Name it blocks as full behavioral sentences: it('should display error message when email is invalid') not it('email test').
• Keep each it block focused on one assertion concern. Use expect for one logical outcome per test. Multiple expect calls are acceptable when they describe one compound fact (e.g., asserting both length and content of an array).
• Extract repeated setup into factory functions: function createComponent(inputOverrides = {}) that returns { fixture, component, service }. This avoids massive beforeEach blocks.
• Target a test file line count below 400 lines. If you exceed this, split into component-name.component.spec.ts (template tests) and component-name.service.spec.ts pattern, or group by feature area.

8. Measure, Enforce, and Optimize Coverage

Coverage is a metric that can mislead if not used carefully, but it is essential for production Angular projects.

• Configure Istanbul (built into Angular's karma setup, or via @jest/coverage for Jest) in angular.json or jest.config.ts. Set thresholds: statements: 80, branches: 75, functions: 80, lines: 80 as a production baseline.
• Coverage thresholds in jest.config.ts: use coverageThreshold.global object. CI should fail if thresholds are not met.
• Focus on branch coverage more than line coverage. An 80% line coverage can hide 50% branch coverage if ngIf conditions are never tested in their false state.
• Use ng test --code-coverage and inspect the HTML report in coverage/ folder. Red lines indicate uncovered branches, not just uncovered lines.
• Do NOT add /* istanbul ignore next */ comments without a team code review. Overuse of ignore comments corrupts coverage metrics.
• Profile test suite speed with --verbose flag. Identify the 10 slowest tests. Tests taking over 2 seconds individually are misconfigured -- likely importing too many modules or using real timers.
• Target a full test suite execution time under 60 seconds for projects up to 200 components. Above 60 seconds, investigate parallelization via Jest's --runInBand removal or Karma's parallel execution config.

---

Output Format

When helping a user implement or review Angular testing patterns, provide output in this structure:

## Angular Test Implementation Plan

### Test Classification
- Component/Service/Directive under test: [name]
- Test type: [Isolated Unit | Shallow Component | Deep Integration | TestBed Service]
- Async complexity: [None | Observable | HTTP | fakeAsync required | Signals]
- Dependencies to mock: [list with mock strategy for each]

### TestBed Configuration
\`\`\`typescript
TestBed.configureTestingModule({
  declarations: [],   // Only this component + any needed stubs
  imports: [],        // Targeted modules only
  providers: [],      // Typed spy objects or MockProvider
  schemas: []         // NO_ERRORS_SCHEMA if shallow
});
\`\`\`

### Dependency Mock Strategy

| Dependency | Mock Type | Rationale |
|------------|-----------|-----------|
| HttpClient | HttpClientTestingModule + HttpTestingController | Verifies request URL/method/body |
| UserService | jasmine.createSpyObj / jest.fn() | Returns controlled observables |
| Router | RouterTestingModule or plain stub | Depends on navigation assertion needs |
| NgRx Store | provideMockStore({ initialState }) | Avoids real reducer execution |

### Test Structure Template
\`\`\`typescript
describe('ComponentName', () => {
  let fixture: ComponentFixture<ComponentName>;
  let component: ComponentName;
  let dependencySpy: jasmine.SpyObj<DependencyService>;

  beforeEach(async () => {
    // Setup
  });

  describe('when [initial state / precondition]', () => {
    it('should [expected behavior]', () => {
      // Arrange
      // Act
      // Assert
    });
  });
});
\`\`\`

### Coverage Targets
- Statement coverage: [80%+ recommended]
- Branch coverage: [75%+ recommended, focus on ngIf/ternary/switch]
- Critical paths requiring 100%: [auth guards, form validation, error states]

### Known Edge Cases to Test
- [List 3-5 specific edge cases relevant to this component/service]

---

Rules

1. NEVER import AppModule, SharedModule, or any barrel module into a TestBed configuration. These pull in the entire application dependency graph, inflate test compilation time by 10-50x, and create hidden coupling. Always import only the exact Angular modules your template actually uses.

2. NEVER use NO_ERRORS_SCHEMA in deep integration tests. This schema silently suppresses errors for unknown elements AND unknown attribute bindings. Use it only for deliberately shallow tests where you want to ignore child components. For integration tests, declare stub components explicitly.

3. ALWAYS call httpMock.verify() in afterEach when using HttpClientTestingModule. Omitting this call means unexpected or extra HTTP requests silently pass, hiding bugs where components make too many requests or request wrong endpoints.

4. NEVER use setTimeout or real Promise chains in Angular tests without waitForAsync or fakeAsync. Real timers create race conditions in test execution and cause intermittent failures in CI environments with different CPU scheduling. Always use fakeAsync + tick() for deterministic time control.

5. ALWAYS use NoopAnimationsModule instead of BrowserAnimationsModule in test modules. Real animation modules start timer-based animation callbacks that require fakeAsync tick management throughout unrelated tests and cause phantom failures when animations complete during teardown.

6. NEVER assert on component internals (private properties, internal state) when you can assert on the rendered output instead. Testing component.isLoading === true is less valuable than testing that the loading spinner is in the DOM. Internal state can change while behavior remains correct -- only behavior assertions protect against real regressions.

7. ALWAYS use TestBed.inject() instead of TestBed.get() for Angular 9+ projects. TestBed.get() is deprecated, untyped, and returns any. TestBed.inject(Token) is type-safe and provides compile-time verification that the token exists in the test module.

---

Edge Cases

Testing Components with OnPush Change Detection

Components using ChangeDetectionStrategy.OnPush do not re-render on every detectChanges() call -- they only re-render when @Input references change, events fire, or the async pipe emits. This breaks naive tests that set component.someProperty = newValue and then call detectChanges().

Handling:

• Use fixture.componentRef.setInput('inputName', value) (Angular 14+) to trigger OnPush re-renders for @Input changes. This correctly marks the component dirty.
• For service observables bound via async pipe, ensure the observable emits (e.g., call subject.next(newValue)) before calling detectChanges(). The async pipe handles the subscription internally.
• Alternatively, inject ChangeDetectorRef via fixture.debugElement.injector.get(ChangeDetectorRef) and call cdr.markForCheck() then fixture.detectChanges() to force a check cycle.
• Use ComponentRef.setInput not component.inputName = value as the primary mechanism. The latter bypasses the Angular input setter pipeline in OnPush components.

Testing Angular Router Guards

Route guards (CanActivate, CanDeactivate, CanLoad, CanMatch) are often tested incorrectly by instantiating them as isolated classes and passing raw objects as ActivatedRouteSnapshot. This misses DI-dependent guard logic.

Handling:

• For guards with no complex template interaction, use isolated unit tests: new MyGuard(authServiceSpy, routerSpy). Create minimal mock route snapshots: { paramMap: convertToParamMap({ id: '1' }) } as ActivatedRouteSnapshot.
• For guards that interact with the router navigation pipeline, use RouterTestingModule.withRoutes(testRoutes) in an integration test. Navigate with router.navigate(['/protected']) inside fakeAsync/tick, then assert on router.url.
• Assert the boolean return value for simple guards. For guards returning UrlTree, assert with router.createUrlTree(['/login']) equality using expect(result.toString()).toBe('/login').
• For CanDeactivate guards, directly call guard.canDeactivate(componentInstance, route, state) with a spy on the component's canLeave method.

Testing Components with Complex RxJS Chains and switchMap/combineLatest

Components that combine multiple observables or use higher-order operators like switchMap, mergeMap, or combineLatest create intricate timing dependencies in tests.

Handling:

• Use BehaviorSubject for simulating multiple observable inputs: create one BehaviorSubject per input stream, inject them through service spies, and control emissions manually.
• For switchMap cancelation behavior, test that starting a second emission cancels the first. Emit twice from the source subject before the inner observable completes. Verify only the second result appears.
• For combineLatest, remember it does not emit until ALL source observables have emitted at least once. Initialize BehaviorSubject instances with initial values to avoid tests that never emit.
• Use cold and hot observables from rxjs/testing's TestScheduler when timing relationships between operators are the primary thing being tested. This is more explicit than fakeAsync for pure RxJS logic.
• Avoid take(1) workarounds in tests -- they mask subscription completion issues. Let subscriptions run for the expected number of emissions and verify counts.

Testing NgRx Effects

Effects are the most complex testing surface in NgRx applications because they involve action streams, service calls, and dispatched output actions.

Handling:

• Use provideMockActions from @ngrx/effects/testing to create a controllable Observable<Action> input stream.
• Structure the test: push an action into the actions$ subject, then subscribe to the effect observable, and assert on the emitted action.
• For effects with switchMap to services, return of(result) from service spies for synchronous testing. For effects with error handling (catchError), make the service spy throw: serviceSpy.getData.and.returnValue(throwError(() => new Error('500'))).
• Verify both the success action type and payload: expect(dispatchedAction).toEqual(loadUsersSuccess({ users: mockUsers })).
• For effects that dispatch no action ({ dispatch: false }), use toBeObservable(cold('-')) from jasmine-marbles or simply subscribe and verify the side effect occurred.
• Do NOT test the entire NgRx chain (action -> reducer -> selector -> effect) in a unit test. That belongs in an integration test or e2e test.

Migrating from Karma/Jasmine to Jest

Teams migrating an existing Angular project from Karma to Jest encounter several sharp edges that are not covered in basic migration guides.

Handling:

• Install jest, jest-environment-jsdom, @jest/globals, ts-jest, and jest-preset-angular. Remove karma, karma-jasmine, karma-chrome-launcher, and @types/jasmine.
• Add "types": ["jest"] to tsconfig.spec.json to prevent TypeScript from complaining about missing Jasmine globals.
• Replace jasmine.createSpyObj with jest.fn() typed mocks. Replace spy.and.returnValue(x) with mockSpy.mockReturnValue(x) and spy.and.callFake(fn) with mockSpy.mockImplementation(fn).
• Replace spyOn(obj, 'method').and.returnValue(x) with jest.spyOn(obj, 'method').mockReturnValue(x).
• jasmine.objectContaining becomes expect.objectContaining. jasmine.arrayContaining becomes expect.arrayContaining.
• Watch for zone.js import issues. Add import 'zone.js' and import 'zone.js/testing' to setup-jest.ts entry file.
• Run jest --runInBand during migration to surface issues in serial execution before enabling parallelism.

Testing Standalone Components (Angular 14+)

Standalone components do not use NgModule, which changes how TestBed is configured and how dependencies are resolved.

Handling:

• Use TestBed.configureTestingModule({ imports: [StandaloneComponent, MockChildComponent] }). Standalone components go in imports, not declarations.
• Override providers using TestBed.overrideComponent(StandaloneComponent, { set: { providers: [{ provide: MyService, useValue: mockService }] } }) for component-level providers defined in the component's own providers array.
• Use importProvidersFrom(HttpClientTestingModule) or provideHttpClientTesting() in the providers array for standalone components that use HttpClient.
• Standalone pipes and directives used in the component's template must appear in the component's imports -- ensure your test either imports the real artifact or provides a stub with the same selector.
• Angular 17+ functional guards and resolvers are pure functions -- test them as isolated functions with no TestBed required. Pass mock arguments directly.

Diagnosing and Fixing Flaky Tests in CI

Tests that pass locally but fail in CI, or fail on every 5th run, indicate one of a small set of root causes in Angular.

Handling:

• Timer leakage: Add discardPeriodicTasks() and flush() at the end of all fakeAsync blocks. Unreleased timers carry into subsequent tests in Jest's same worker process.
• Subscription leakage: Ensure components under test call ngOnDestroy. Manually trigger it: fixture.destroy() in afterEach -- Angular's destroyAfterEach option handles this automatically.
• Test order dependency: Run Jest with --randomize flag to shuffle test order and surface order-dependent failures. Identify the test that "prepares" state for the failing test.
• Zone.js scheduling differences: CI machines are single-core -- microtask queue ordering can differ. Replace all Promise.resolve().then(...) chains in source code with scheduled(observable, asyncScheduler) from RxJS for consistent ordering.
• DOM state from previous test: document.body is shared across all tests in the same jsdom instance. Components that append to document.body (overlays, dialogs) must clean up in ngOnDestroy. Test by running the test that appends in isolation versus in sequence.

---

Example

Input: "I have an Angular 16 component called UserProfileComponent that loads user data via UserService.getUser(id) which returns an Observable<User>. It displays the user's name, shows a loading spinner while fetching, and shows an error message if the request fails. It uses OnPush change detection. How do I write comprehensive tests for this?"

Output:

Test Classification

• Component under test: UserProfileComponent
• Test type: Shallow Component (mock UserService, no real HTTP)
• Async complexity: Observable + fakeAsync required for error scenarios
• Change detection: OnPush -- requires setInput() for @Input changes, observable emissions for async pipe re-renders
• Dependencies to mock: UserService via jasmine.createSpyObj, ActivatedRoute via { params: of({ id: '42' }) }

Complete Test File

import { ComponentFixture, TestBed, fakeAsync, tick } from '@angular/core/testing';
import { By } from '@angular/platform-browser';
import { NO_ERRORS_SCHEMA } from '@angular/core';
import { ActivatedRoute } from '@angular/router';
import { of, throwError, Subject } from 'rxjs';

import { UserProfileComponent } from './user-profile.component';
import { UserService } from '../services/user.service';
import { User } from '../models/user.model';

const mockUser: User = {
  id: '42',
  name: 'Jane Smith',
  email: '[e-mail]',
  role: 'admin'
};

describe('UserProfileComponent', () => {
  let fixture: ComponentFixture<UserProfileComponent>;
   : ;
   : jasmine.<>;

  ( () => {
    userServiceSpy = jasmine.<>(, []);

     .({
      : [],
      
      : [],
      : [
        { : , : userServiceSpy },
        {
          : ,
          : { : ({ :  }) }
        }
      ]
    }, { : { :  } }).();

    
  });

  
   ():  {
    fixture = .();
    component = fixture.;
  }

  (,  {
    (,  {
      
       userSubject =  <>();
      userServiceSpy...(userSubject.());
      ();

      
      fixture.();

      
       spinner = fixture..(.());
      (spinner)..();

      
       nameEl = fixture..(.());
      (nameEl).();
    });

    (,  {
      
      userServiceSpy...((mockUser));
      ();

      
      fixture.();

      
      (userServiceSpy.).();
    });
  });

  (,  {
    ( {
      userServiceSpy...((mockUser));
      ();
      fixture.(); 
    });

    (,  {
       nameEl = fixture..(.());
      (nameEl...()).();
    });

    (,  {
       emailEl = fixture..(.());
      (emailEl...()).();
    });

    (,  {
       spinner = fixture..(.());
      (spinner).();
    });

    (,  {
       errorEl = fixture..(.());
      (errorEl).();
    });

    (,  {
       badge = fixture..(.());
      (badge)..();
    });
  });

  (,  {
    ( {
      userServiceSpy...(
        (  ())
      );
      ();
      fixture.();
    });

    (,  {
       errorEl = fixture..(.());
      (errorEl)..();
      (errorEl...()).();
    });

    (,  {
       spinner = fixture..(.());
      (spinner).();
    });

    (,  {
       nameEl = fixture..(.());
      (nameEl).();
    });
  });

  (,  {
    (, ( {
      
      userServiceSpy...((mockUser));
      ();
      fixture.();

      
       :  = { ...mockUser, : , :  };
      userServiceSpy...((updatedUser));

      
      fixture..(, );
      (); 
      fixture.();

      
       nameEl = fixture..(.());
      (nameEl...()).();
      (userServiceSpy.).();
    }));
  });

  (,  {
    (, ( {
      
      userServiceSpy...(
        (  ()),
        (mockUser)
      );
      ();
      fixture.();

      
       errorEl = fixture..(.());
      (errorEl)..();

      
       retryBtn = fixture..(.());
      retryBtn..();
      ();
      fixture.();

      
       nameEl = fixture..(.());
      (nameEl...()).();
      (userServiceSpy.).();
    }));
  });
});

Coverage Assessment for This Component

Coverage Area	Tests Covering It	Branch Status
Loading state (true)	should show loading spinner before data arrives	Covered
Loading state (false -- success)	should hide the loading spinner after data arrives	Covered
Loading state (false -- error)	should hide the loading spinner on error	Covered
Success render (name, email)	should display the user name/email	Covered
Error render	should display the error message	Covered
Role-based badge (admin)	should display admin badge	Partially -- need non-admin test
Role-based badge (non-admin)	Not yet written -- add it('should not display admin badge for non-admin')	Missing branch
Retry logic	should retry loading when retry button is clicked	Covered
Route param extraction	should call getUser with the route param id	Covered
Input change re-fetch	should reload user when userId input changes	Covered

What to Add Next

The non-admin role branch is the only missing branch coverage item. Add:

it('should not display admin badge when user role is viewer', () => {
  const viewerUser: User = { ...mockUser, role: 'viewer' };
  userServiceSpy.getUser.and.returnValue(of(viewerUser));
  createComponent();
  fixture.detectChanges();

  const badge = fixture.debugElement.query(By.css('[data-testid="admin-badge"]'));
  expect(badge).toBeNull();
});

This brings branch coverage to 100% for the role display conditional, which is a user-facing behavior difference warranting full branch coverage.