julien
c8e2fba13e
Rewrites all 12 frontend ADRs from a custom structure to the MADR 2.1.2 template required by the VS Code ADR Manager extension: bullet metadata (Status/Date), standardised section headings, "Chosen option: X, because Y" wording, and explicit Pros/Cons blocks per option.
52 lines
1.9 KiB
Markdown
52 lines
1.9 KiB
Markdown
# Keep Karma + Jasmine as the test stack
|
|
|
|
- Status: accepted
|
|
- Date: 2026-04-26
|
|
|
|
## Context and Problem Statement
|
|
|
|
Angular's default test setup uses Karma as the test runner (executing tests in a real Chrome browser) and Jasmine as the spec framework. Faster alternatives exist. Should the test stack be replaced?
|
|
|
|
## Considered Options
|
|
|
|
- Karma + Jasmine (Angular default)
|
|
- Jest (Node/jsdom, no real browser)
|
|
- Vitest (ESM-native, no real browser)
|
|
|
|
## Decision Outcome
|
|
|
|
Chosen option: "Karma + Jasmine", because the test suite (54 specs) is small enough that Karma's startup overhead is not a bottleneck, and migration would require replacing test utilities and adjusting Angular `TestBed` setup with no functional gain at the current scale.
|
|
|
|
### Positive Consequences
|
|
|
|
- Zero migration effort — full compatibility with Angular's `TestBed` and `ComponentFixture` APIs.
|
|
- Tests run in a real Chrome browser, catching browser-specific issues that jsdom misses.
|
|
|
|
### Negative Consequences
|
|
|
|
- Slower startup than Jest or Vitest due to Chrome launch. Acceptable at the current test suite size.
|
|
|
|
## Pros and Cons of the Options
|
|
|
|
### Karma + Jasmine
|
|
|
|
- Good, because zero migration cost from the Angular default.
|
|
- Good, because tests run in a real browser environment.
|
|
- Bad, because slower startup than headless alternatives.
|
|
|
|
### Jest
|
|
|
|
- Good, because fast — runs in Node via jsdom with no browser launch.
|
|
- Bad, because requires `jest-preset-angular`, removal of `zone.js/testing`, and test utility changes.
|
|
- Bad, because jsdom is not a real browser — some browser-specific behaviours are not caught.
|
|
|
|
### Vitest
|
|
|
|
- Good, because ESM-native, fastest option.
|
|
- Bad, because Angular `TestBed` integration requires additional configuration.
|
|
- Bad, because jsdom limitation applies here too.
|
|
|
|
## Links
|
|
|
|
- Future consideration: if the test suite grows significantly or CI performance becomes a concern, evaluate migration to Jest with `jest-preset-angular`.
|