iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For a new Angular CLI project, the current documented default is Vitest with jsdom; run ng test to start tests in watch mode. Choose the test boundary to match what you need to verify: test plain logic directly, use TestBed for Angular dependency injection and providers, exercise components through the DOM when templates or user interaction matter, and use browser mode when real browser behavior is part of the feature.
These defaults describe new CLI projects, not every Angular application. Check your project’s existing runner and CLI configuration before changing commands or migrating tests.
Choose the testing boundary that matches the behavior
Angular’s testing guidance ranges from isolated class logic to tests running in a real browser. The practical trade-off is fidelity: a narrow test is simpler and focuses on a small unit, while DOM and browser tests exercise more of the application environment. Angular’s documentation does not present these distinctions as performance measurements.
| Test boundary | What it exercises | When it fits |
|---|---|---|
| Direct class test | Plain TypeScript behavior without Angular’s environment | Logic that does not depend on Angular, rendering, or injection |
| TestBed test | Angular’s configured testing environment, including dependency injection and providers | Services or other behavior that relies on Angular wiring |
| Component DOM test | A component’s class and template working together, including rendered output and interaction | Behavior involving rendering, input, or user interaction |
| Browser-mode test | Execution in a browser rather than jsdom’s simulated DOM | Browser-specific APIs, rendering behavior, or browser debugging |
Angular describes a component as its template and class working together. A class-only test can still verify behavior that needs no DOM, but it cannot establish that the rendered component behaves correctly. See Angular’s component testing basics and the testing overview.
What runner does Angular use?
New Angular CLI projects: Vitest
The current Angular testing overview says new Angular CLI projects include Vitest and jsdom. The documented ng test command builds in watch mode and launches the test runner. jsdom supplies a simulated DOM; it is not the same as running the test in a browser.
Existing projects: inspect before changing
Do not assume an older application uses Vitest. Angular continues to support Karma, including with Jasmine. Follow the runner already configured in the project unless you have chosen to migrate; Angular provides a Karma and Jasmine guide. The current overview does not set a single runner for every Angular project or specify one Angular version boundary for these defaults.
Angular’s testing utility API includes some descriptions and examples framed around Karma and Jasmine while being updated for Vitest. If an example’s runner-specific setup differs from your project, use guidance for the runner actually configured.
Recommended Free Tools
Test services with TestBed and controlled dependencies
TestBed configures an isolated Angular testing environment and lets a test retrieve injected services. This is useful when the behavior under test depends on Angular’s dependency injection or providers, rather than just a class’s methods.
Service tests can replace dependencies with substitutes, so a test can focus on the service behavior without relying on every real collaborator. For services that make HTTP requests, Angular’s testing utilities let tests control HTTP responses instead of depending on a live server. See Angular’s service testing guide for the documented approach.
Test components through the DOM when the template matters
A component’s class can be tested directly for logic that does not require rendering. For behavior involving the template, rendered content, user input, or interaction between the view and class, use a DOM test so the test checks the component as a working unit. Angular’s component guidance emphasizes that the class and template work together; testing only the class cannot verify that interaction.
Rank #4
For the normal new-project setup, jsdom provides a DOM simulation. If the behavior depends on browser-specific APIs or actual browser rendering, use browser mode instead of treating the simulated DOM as proof of browser behavior.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →When to use browser mode
Angular documents browser mode for cases where browser APIs, rendering, or browser-based debugging matter. The overview describes providers for Playwright and WebdriverIO. Browser mode requires installing and configuring a provider; it is not an automatic property of the default jsdom setup. Consult the Angular testing overview for provider configuration examples.
Best Value
Run tests, coverage, and CI
Run locally in watch mode
- From the Angular project, run
ng test. - In the documented new-project workflow, the CLI builds in watch mode and launches the runner; keep it open while changing code to rerun tests.
Generate coverage
Run ng test --coverage to produce a coverage report in the coverage/ directory, as described in Angular’s testing overview. Coverage reports describe which code was exercised; they do not by themselves establish that the tests verify the right behavior.
Run non-interactively in CI
Angular documents that setting CI=true is detected to run the standard command as a non-interactive, single run. If you need to specify the non-watch behavior explicitly, the overview gives ng test --no-watch --no-progress.
Karma CI configuration
For Karma, Angular’s dedicated guide documents ng test --no-watch --no-progress --browsers=ChromeHeadless. Use this runner-specific command only when the project is configured for Karma; do not substitute it automatically into a Vitest project. See the Karma guide.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsQuick Recap
A practical decision path
- If the behavior is ordinary class logic with no Angular dependency, test the class directly.
- If Angular injection, providers, or service wiring is part of the behavior, use
TestBed. - If the component’s rendered template or interaction with users matters, test it through the DOM.
- If a browser API or actual browser rendering is essential, configure browser mode with a supported provider.
- Before running CI or migration commands, confirm which runner the project already uses.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
