Files
adastra_app/docs/decisions/0008-testing-karma-jasmine.md
julien c8e2fba13e docs(adr): convert all ADRs to MADR 2.1.2 format
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.
2026-04-26 16:50:34 +02:00

1.9 KiB

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.
  • Future consideration: if the test suite grows significantly or CI performance becomes a concern, evaluate migration to Jest with jest-preset-angular.