julien/adastra_app
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(adr): convert all ADRs to MADR 2.1.2 format

Browse Source 
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.
This commit is contained in:
Julien Gautier
2026-04-26 16:50:34 +02:00
parent 8f2632f456
commit c8e2fba13e
12 changed files with 478 additions and 191 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/decisions/0008-testing-karma-jasmine.md
+43 -13
View File
@@ -1,21 +1,51 @@
# ADR 0008: Testing — Karma + Jasmine
# Keep Karma + Jasmine as the test stack
**Date:** 2026-04-26
**Status:** Accepted
- Status: accepted
- Date: 2026-04-26
## Context
## 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 assertion/spec framework. Alternatives include Jest (runs in Node via jsdom, no real browser) and Vitest (ESM-native, faster).
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?
Migrating to Jest or Vitest would require changing test utilities, removing `zone.js/testing`, and potentially adjusting Angular testing module setup.
## Considered Options
## Decision
- Karma + Jasmine (Angular default)
- Jest (Node/jsdom, no real browser)
- Vitest (ESM-native, no real browser)
Keep Karma + Jasmine. The test suite (54 specs) is small enough that Karma's startup overhead is not a bottleneck. The default Angular TestBed utilities work without modification.
## Decision Outcome
## Consequences
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:** Zero migration effort. Full compatibility with Angular's `TestBed` and `ComponentFixture` APIs.
- **Positive:** Tests run in a real browser, catching browser-specific issues that jsdom misses.
- **Negative:** Slower startup than Jest/Vitest due to Chrome launch. Acceptable at the current test suite size.
- **Future consideration:** If the test suite grows significantly or CI performance becomes a concern, evaluate migration to Jest with `jest-preset-angular`.
### 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`.