Mocking replaces a dependency with a test-specific implementation so a unit test can examine one class or component in isolation. The replacement keeps the dependency’s relevant API but avoids testing trusted framework code or separately tested application parts. section 8.1.2 section 8.2.3
A mock can be deliberately minimal: an empty HTTP-like service, a component with matching inputs and outputs, or a service object whose methods return controlled values. It also lets a test verify that the subject calls expected methods or properties in the expected order. Hand-writing these replacements becomes repetitive when a component has many injected services or child components. section 8.2.3
Use Angular testing replacements according to the dependency type:
- Use RouterTestingModule for router-related building blocks rather than configuring the real router. section 8.3.2
- Use ng-mocks MockComponents for child components that need matching selectors, inputs, and outputs but no templates or injected dependencies. section 8.3.2
- Use a partial service mock or MockProvider when testing a service that depends on another service; return controlled Observables and implement only behavior needed by the scenario. section 8.3.5
Isolating an application shell
An AppComponent containing a header, router outlet, and footer can be configured with RouterTestingModule plus MockComponents(HeaderComponent, FooterComponent). The setup allows creation and title tests to run without rendering or validating the real child components. A remaining assertion may still fail when it expects text removed from the updated template; that is an expectation failure, not a mocking setup failure. section 8.3.2
Controlling a signal-based service
A TimeOffManagementService can receive a partial TimeOffRequestService mock with Jest functions returning mock request Observables. Tests then create an empty stub component and trigger change detection to observe updates to requests signals after approval, rejection, or deletion. section 8.3.5
Listing 8.14 Mocking the dependencies of a service with signals
const mockRequests: TimeOffRequest[] = [ #1
{
id: 1,
type: 'Vacation',
status: 'Pending',
startDate: new Date().toISOString(),
endDate: new Date().toISOString(),
employeeId: 1,
},
{
id: 2,
type: 'Sick Leave',
status: 'Pending',
startDate: new Date().toISOString(),
endDate: new Date().toISOString(),
employeeId: 1,
},
];
const MockTimeOffRequestService: Partial<
TimeOffRequestService
> = { #2
getRequestsByType: jest.fn()
.mockReturnValue(
of(mockRequests),
), #3
approveRequest: jest.fn()
.mockImplementation(
(id) => { #4
const request = mockRequests
.find(
(r) =>
r.id === id
);
if (request) {
request.status = 'Approved';
}
return of({});
}),
rejectRequest: jest.fn().mockImplementation((id) => {
const request = mockRequests.find((r) => r.id === id);
if (request) {
request.status = 'Rejected';
}
return of({});
}),
deleteRequest: jest.fn().mockImplementation((id) => {
const index = mockRequests.findIndex((r) => r.id === id);
if (index !== -1) {
mockRequests.splice(index, 1);
}
return of({});
}),
};
let localStorageMock: Pick<
Storage, 'getItem' | 'setItem'
>; #5
let selectedType = '';
let service: TimeOffManagementService;
describe('TimeOffManagementService', () => {
beforeEach(() => {
TestBed.configureTestingModule({
providers: [
MockProvider(
TimeOffRequestService,
MockTimeOffRequestService,
)
],
});
localStorageMock = {
getItem: jest.fn()
.mockReturnValue(
() => selectedType,
), #6
setItem: jest.fn().mockImplementation((key, value) => {
selectedType = value; #7
})
};
Object.defineProperty(window, 'localStorage', {
value: localStorageMock,
});
TestBed.runInInjectionContext(() => {
service = new TimeOffManagementService();
});
});
it('should be successfully instantiated', () => {
expect(service).toBeTruthy(); #8
});
});
This mock defines predictable time-off data and service methods, including Observable returns and request-state updates, for focused service tests. section 8.3.5
ng-mocks can automatically mock services, components, pipes, and other Angular building blocks, reducing replacement boilerplate. AI-generated mock data or service implementations can accelerate mechanical setup, but service mocks still require judgment about methods, return values, and the behavior the test must control. section 8.2.3 section 8.4.1
When extending tests, change mock data and mock implementations together when the scenario requires different dependency behavior—for example, verifying that selecting a request type updates the UI. Existing Karma-based test suites can also be migrated to Jest and investigated for resulting issues. section 8.6
