frontend-testing-strategy

# Frontend testing strategy Write tests for Grafana frontend code that pass review on the first pass. Goals: **assert concrete behavior, not existence**; keep test descriptions honest; verify the test actually exercises the target code path; and stabilize the known flake classes. Several codeowner paths are opted into the gating `check-frontend-test-coverage.yml` check, so coverage that drops fails CI. ## Resolve the target Interpret the argument to decide scope: - **A file path** → test that file (create or extend its co-located `*.test.ts(x)`). - **A directory / component / module name** → the source files under it lacking meaningful coverage. - **"current file" / no path but a file is open** → the open file. - **No argument** → ask which file/area; don't blanket-generate. Prefer extending an existing co-located test file over adding a new one. Match the surrounding test file's imports and idiom. ## Principle 1 — Where each test fits: the (inverted) testing diamond Testing model, top to bottom: - **E2E** (pinnacle) — validate the system via real user flows; powerful but slow, so keep it targeted and few. - **Unit** (base) — cheap, plentiful specs documenting behavior for logic/utils. - **Static analysis** (foundation) — lint + strong TypeScript interfaces. Pick the layer that matches the job: logic/IO → unit; how pieces fit together → integration/visual; a key user journey → E2E. **Favour speed and feedback** — unit tests are cheap, so make them small and plent...