# Frontend Test Robustness Resources

Curated for the Flowbase suite. Every entry says when to reach for it.

> Absorbs the former `concurrency/RESOURCES.md`. Both gaps recorded there are now closed:
> per-worker database isolation by the [Testcontainers](https://testcontainers.com/) entry below (as a price tag, not a
> recommendation), and flake budgets / quarantine as an operational practice by the Spotify,
> Google and Kowalczyk entries.

## Knowledge — flakiness, empirically

- [Paper: "An Empirical Analysis of Flaky Tests" — Luo, Hariri, Eloussi & Marinov (FSE '14)](https://www.cs.cornell.edu/courses/cs5154/2021sp/resources/LuoETAL14FlakyTestsAnalysis.pdf)
  The origin of the flake taxonomy everyone else cites: 201 flake-fixing commits across 51
  projects, sorted into ten root causes, with the *fix strategies* tabulated separately from
  the causes. Async-wait, test order dependency and concurrency are the top three.
  Use for: the canonical vocabulary. Every flake in the suite should get a label from this
  table before anyone proposes a fix. ([ACM page](https://dl.acm.org/doi/10.1145/2635868.2635920), paywalled.)

- [Paper: "An Empirical Study of Flaky Tests in JavaScript" — Hashemi, Tahir & Rasheed (ICSME 2022)](https://arxiv.org/pdf/2207.01047)
  The Luo taxonomy re-run on JS/TS. Async calls dominate even harder, and **Platform** —
  OS, browser build, font rendering, CPU count — is unusually large compared with other
  ecosystems.
  Use for: the ecosystem-specific prior on where to look first. Read alongside the UI-flake
  study below; between them they cover this suite's actual distribution.

- [Survey: "A Survey of Flaky Tests" — Parry, Kapfhammer, Hilton & McMinn (TOSEM 2021)](https://eprints.whiterose.ac.uk/id/eprint/230095/1/parry2021.pdf)
  74 pages, four parts: causes, costs, detection, mitigation. The one place the whole field is
  mapped, including the definitional fights (is an order-dependent test "flaky"?).
  Use for: the detection section — how you decide a test *is* flaky without infinite reruns —
  and as the index for finding a primary source on any sub-problem.

- [Paper: "An Empirical Analysis of UI-based Flaky Tests" — Romano, Song, Grandhi, Yang & Wang (ICSE '21)](https://arxiv.org/pdf/2103.02669)
  The closest paper to this mission: flakiness in *browser* tests specifically, where the
  causes skew differently from unit tests — async waits on rendering, resource rendering,
  animation, and environment. Also quantifies how much longer UI flakes take to fix.
  Use for: the argument that a browser suite's flake profile is its own thing, and for the
  categories to expect in `e2e/` that the Luo taxonomy under-weights.

- [Paper: "iDFlakies: A Framework for Detecting and Partially Classifying Flaky Tests" — Lam, Oei, Shi, Marinov & Xie (ICST '19)](https://taoxie.cs.illinois.edu/publications/icst19-idflakies.pdf)
  Where **order-dependent (OD)** vs **non-order-dependent (NOD)** gets defined properly, along
  with **polluter**, **victim**, **brittle** and **cleaner**. The method is simple and stealable:
  run the suite in randomised orders and diff the outcomes.
  Use for: the terms to use when a spec passes alone and fails in the suite, and for the
  shuffle-the-order experiment to run against the Flowbase projects.

- [Paper: "iFixFlakies: A Framework for Automatically Fixing Order-Dependent Flaky Tests" — Shi, Lam, Oei, Xie & Marinov (ESEC/FSE '19)](https://taoxie.cs.illinois.edu/publications/esecfse19-ifixflakies.pdf)
  The follow-up: an OD test usually has a **cleaner** already in the suite — some other test
  that undoes the pollution — so the fix is often to move existing code, not write new code.
  Use for: the insight that maps directly onto the `e2e/CLAUDE.md` teardown rules.

- [Paper: "The Effects of Computational Resources on Flaky Tests" — Parry, Kapfhammer, Hilton & McMinn (TSE 2024)](https://arxiv.org/pdf/2310.12132)
  The most directly actionable paper in this list for Flowbase. Defines **resource-affected**
  tests — flaky specifically as a function of available CPU, memory and I/O — and measures how
  many flakes are actually a machine under load rather than a bug in the test.
  Use for: the eight-workers-plus-5s-`actionTimeout` question. If a meaningful share of flakes
  are resource-affected, the fix is a worker count or a shard, not a locator.

- [Paper: "Taming Timeout Flakiness: An Empirical Study of SAP HANA" — Zhang et al. (2024)](https://arxiv.org/pdf/2402.05223)
  Timeout-induced flakiness as its own category, at scale, with the tradeoff stated plainly:
  a tighter timeout catches regressions and manufactures flakes; a looser one hides both.
  Use for: defending — or revising — the deliberate `expect.timeout: 5_000` /
  `actionTimeout: 5_000` choice, with an argument rather than a preference.

- [Paper: "Empirically Evaluating Flaky Test Detection Techniques Combining Test Rerunning and Machine Learning" — Parry et al. (EMSE 2023)](https://eprints.whiterose.ac.uk/id/eprint/198846/1/s10664-023-10307-w.pdf)
  How many reruns you actually need before "it passed" means something, and what rerunning
  costs versus what it detects.
  Use for: choosing the rerun count for a deliberate flake-hunting job — the
  `--repeat-each` run that the suite has never done.

- [Paper: "230,439 Test Failures Later: An Empirical Evaluation of Flaky Failure Classifiers" — Parry et al. (2024)](https://arxiv.org/pdf/2401.15788)
  Evaluates the classifiers that decide, from one failure, whether it was a flake. The
  headline result is how unreliable that judgement is.
  Use for: resisting the instinct to eyeball a red run and call it flaky.

## Knowledge — flakiness at industrial scale, and what to do about it

- [Article: "Flaky Tests at Google and How We Mitigate Them" — John Micco (2016)](https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html)
  The numbers: ~1.5% of all test runs are flaky, 16% of tests show *some* flakiness, and 84%
  of pass→fail transitions involve a flaky test. Also the honest account of rerun-based
  mitigation and what it costs in machine time.
  Use for: calibration — what a normal flake rate is — and for the argument that reruns are a
  cost centre, not a fix.

- [Article: "Where do our flaky tests come from?" — Micco & Fowler, Google (2017)](https://testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-from.html)
  The single most decision-relevant finding for Flowbase: flakiness correlates with test
  *size* and with the number of dependencies, not with the code under test. Larger tests are
  flakier almost regardless of what they test.
  Use for: the case that a one-level, all-large suite has a floor on its flake rate that no
  amount of careful locator hygiene will get under.

- [Article: "Test Flakiness — One of the Main Challenges of Automated Testing", Parts I and II — George Pirocanac, Google (2020, 2021)](https://testing.googleblog.com/2020/12/test-flakiness-one-of-main-challenges.html)
  ([Part II](https://testing.googleblog.com/2021/03/test-flakiness-one-of-main-challenges.html).) A
  practitioner's decomposition of where nondeterminism enters — the test, the test framework,
  the system under test and its dependencies, and the infrastructure — and a workflow for
  quarantine and repair.
  Use for: the four-place model to localise a flake before debugging it, and for quarantine
  mechanics.

- [Article: "Test Flakiness — Methods for identifying and dealing with flaky tests" — Spotify Engineering (2019)](https://engineering.atspotify.com/2019/11/test-flakiness-methods-for-identifying-and-dealing-with-flaky-tests)
  A real team's flakiness *policy*: how they score a test's flakiness, the thresholds at which
  it gets quarantined, and who owns fixing it. Includes the visualisation angle (Odeneye).
  Use for: designing the flake-rate metric and the quarantine rule that Flowbase's
  `retries: 3` currently stands in for.

- [Paper: "De-Flake Your Tests: Automatically Locating Root Causes of Flaky Tests in Code at Google" — Ziftci & Cavalcanti (ICSME 2020)](https://research.google/pubs/de-flake-your-tests-automatically-locating-root-causes-of-flaky-tests-in-code-at-google/)
  Bisection over the *test's own execution* rather than over commits, to point at the
  statement responsible. 82% accuracy across 428 projects.
  Use for: the debugging strategy for a flake you cannot reproduce — narrow the test, not the
  history.

- [Paper: "Modeling and Ranking Flaky Tests at Apple" — Kowalczyk, Nair, Gao, Silberstein, Long & Memon (ICSE-SEIP 2020)](https://2020.icse-conferences.org/details/icse-2020-Software-Engineering-in-Practice/2/Modeling-and-Ranking-Flaky-Tests-at-Apple)
  The paper that makes flakiness a **number**: entropy over outcomes plus **flipRate** over
  time, aggregated with decay, producing a rankable score. Deployed on two large services;
  44% flakiness reduction at under 1% loss in fault detection.
  Use for: the exact formula to compute per-spec, and the ranking that says which three specs
  to fix first. This is the metric the mission needs.
  ([IEEE](https://ieeexplore.ieee.org/document/9276599/) for the full text.)

- [Paper: "Understanding Flaky Tests: The Developer's Perspective" — Eck, Palomba, Castelluccio & Bacchelli (ESEC/FSE 2019)](https://arxiv.org/pdf/1907.01466)
  21 Mozilla developers on 200 flaky tests they had personally fixed: how they perceived the
  cause, how long it took, and what they *thought* the cause was versus what it was.
  Use for: the social half of the problem — writing a team standard that people follow
  requires knowing how engineers actually misdiagnose flakes.

- [Paper: "A Survey on How Test Flakiness Affects Developers and What Support They Need" — Habchi, Haben, Papadakis, Cordy & Le Traon (ICST 2022)](https://arxiv.org/pdf/2203.00483)
  What practitioners report needing: not better detection, but attribution and ownership.
  Use for: the shape of the team process around the metric — who gets pinged, and with what.

## Knowledge — what a test is for, and which level owns it

- [Book: _Software Engineering at Google_, Ch. 11 "Testing Overview"](https://abseil.io/resources/swe-book/html/ch11.html)
  Defines **test size** (small / medium / large) as a property of *resources and confinement* —
  threads, processes, machines, network — orthogonal to **scope** (how much code is exercised).
  The **hermetic** requirement lives here: a test carries everything needed to set up, run and
  tear down its own environment.
  Use for: the two-axis vocabulary. Flowbase's suite is uniformly large-size, medium-to-large
  scope; naming that is the first step to changing it.

- [Book: _Software Engineering at Google_, Ch. 12 "Unit Testing"](https://abseil.io/resources/swe-book/html/ch12.html)
  The best available treatment of **testing behaviours, not methods**, of why tests should be
  **unchanging** in the face of refactors, and of **DAMP over DRY** in test code.
  Use for: judging Page Object design — where shared helpers stop aiding and start hiding —
  and for the "test the public API" rule that the black-box convention already half-encodes.

- [Book: _Software Engineering at Google_, Ch. 13 "Test Doubles"](https://abseil.io/resources/swe-book/html/ch13.html)
  Seams, fakes, stubs, mocks and interaction testing, with the strongest statement of the
  preference order: real implementation > fake > stub, and interaction testing last.
  Use for: deciding what a `page.route` interception actually is, and for the cost model of
  faking the Flowbase API instead of running it.

- [Book: _Software Engineering at Google_, Ch. 14 "Larger Testing"](https://abseil.io/resources/swe-book/html/ch14.html)
  The chapter written about suites like this one: what larger tests are *for* (fidelity,
  configuration, emergent behaviour), the **SUT** vocabulary, seeding data, and the
  maintenance burden that makes them expensive.
  Use for: the checklist of what only an E2E test can catch — the test that decides whether a
  spec belongs in `e2e/` at all.

- [Article: "On the Diverse and Fantastical Shapes of Testing" — Martin Fowler (2021)](https://martinfowler.com/articles/2021-test-shapes.html)
  Cuts through pyramid-vs-trophy-vs-honeycomb by pointing out the arguments are about
  undefined words. Introduces **sociable** vs **solitary** unit tests, and lands on the
  criteria that actually matter: fast, reliable, expressive, failing only for useful reasons.
  Use for: the sentence to open the team standards document with, and for the
  sociable/solitary distinction when deciding how much of the app a component test mounts.

- [Article: "Test Desiderata" — Kent Beck (2019)](https://testdesiderata.com/)
  Twelve properties a test can have — isolated, composable, deterministic, fast, writable,
  readable, behavioural, structure-insensitive, automated, specific, predictive, inspiring —
  framed explicitly as **tradeoffs**: give one up only to buy a more valuable one.
  Use for: the spine of the whole mission. "Deterministic" and "isolated" are the two the
  Flowbase suite is currently buying with retries.

- [Article: "The Testing Trophy and Testing Classifications" — Kent C. Dodds](https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications)
  and [Docs: Testing Library — Guiding Principles](https://testing-library.com/docs/guiding-principles/)
  The frontend counter-position to the pyramid, plus the "resemble the way software is used"
  principle that drives Testing Library's role-and-text query priority — which is exactly the
  convention Flowbase bans in favour of test-ids.
  Use for: arguing *both* sides of the selector question honestly, and for knowing what
  static/unit/integration mean in frontend usage before writing rules that use those words.

- [Book: _Unit Testing Principles, Practices, and Patterns_ — Vladimir Khorikov (Manning 2020)](https://www.manning.com/books/unit-testing)
  ([Free summary of the core model.](https://www.sammancoaching.org/learning_hours/test_design/four_pillars_khorikov.html))
  The **four pillars**: protection against bugs, resistance to refactoring, fast feedback,
  maintainability — with the argument that the first two cannot both be maximised, so every
  test is a chosen compromise. Also the sharpest available definition of the **observable
  behaviour vs. implementation detail** line.
  Use for: the framework for arguing about a test in review without it becoming taste.
  Flowbase's black-box rule is a bet on resistance to refactoring; this names the price.

- [Article: "Test size and scope" — Nelson Elhage](https://buttondown.com/nelhage/archive/test-size-and-scope/)
  A short, unusually clear reading of the Google size/scope split, including the observation
  that most arguments about "unit tests" are two people using one word for two axes.
  Use for: the one-page explainer to hand a teammate before a conventions discussion.

- [Article: "Mocks Aren't Stubs" — Martin Fowler](https://martinfowler.com/articles/mocksArentStubs.html)
  The origin of the dummy/stub/spy/mock/fake vocabulary and the **state verification vs.
  behaviour verification** distinction that most of the confusion lives in.
  Use for: naming what a `page.route` handler is (a stub, usually) and what a request
  assertion is (behaviour verification), so the team standard uses the words correctly.

- [Article: "Testing on the Toilet: Test Behavior, Not Implementation" — Google (2013)](https://testing.googleblog.com/2013/08/testing-on-toilet-test-behavior-not.html)
  One page. The rule in its most compressed form, with a before/after.
  Use for: the citation in a code-review comment.

- [Article: "The Practical Test Pyramid" — Ham Vocke (2018)](https://martinfowler.com/articles/practical-test-pyramid.html)
  The long-form treatment: layer definitions, what to test where, and — most relevant here —
  the sections on contract tests and on avoiding duplicated coverage across layers.
  Use for: the "don't test the same thing twice at different levels" argument, which is the
  main lever for cutting CI time without losing coverage.

- [Bliki: "Contract Test" — Martin Fowler](https://martinfowler.com/bliki/ContractTest.html)
  and [Docs: Pact](https://docs.pact.io/)
  Consumer-driven contract testing: the consumer states what it needs, the provider verifies
  it, and neither has to run the other.
  Use for: the alternative to "every test drives the real backend for fidelity". Read
  critically — Pact assumes hand-written clients, and `@/generated` already carries much of
  the contract.

## Knowledge — determinism: time, network, data

- [Library: `@sinonjs/fake-timers`](https://github.com/sinonjs/fake-timers)
  The engine underneath `page.clock` (and Jest/Vitest fake timers). The README documents
  exactly which globals are replaced and — crucially — the semantics of `tick` vs `tickAsync`
  and why advancing a clock does not flush promises.
  Use for: understanding what `page.clock.fastForward` does and does not resolve, which is
  where fake-time tests go subtly wrong.

- [Docs: Mock Service Worker (MSW)](https://mswjs.io/docs/)
  The frontend standard for network interception at the Service Worker / request level, with
  handlers shared between component tests and browser tests.
  Use for: the option Flowbase does not have — one set of API stubs reusable across levels —
  and for the argument that intercepting at the network boundary keeps a test black-box in the
  sense that matters.

- [Docs: React — `act` and the concurrent-rendering caveats](https://react.dev/reference/react/act)
  Why an assertion can run between a state update and its paint, and what `act` actually
  guarantees.
  Use for: the mechanism behind "the DOM briefly showed the old value" flakes, and for why
  `data-editor-synced`-style mirrored state is the correct workaround at the E2E level.

- [Docs: Playwright — Emulation](https://playwright.dev/docs/emulation)
  `reducedMotion`, `colorScheme`, `timezoneId`, `locale`, `geolocation`, viewport.
  Use for: the determinism knobs beyond time and network. `timezoneId` and `locale` are
  unset in the current config, which makes every date and money assertion dependent on the
  machine — a live hazard for the i18n and money-field specs.

- [Docs: MDN — `PointerEvent.getCoalescedEvents()`](https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/getCoalescedEvents)
  How the browser batches high-frequency pointer moves into one dispatched event, and how a
  library recovers the intermediate positions.
  Use for: the precise reason a synthetic drag must step across animation frames — the
  mechanism `lib/editor/dragBetween` is compensating for.

- [Docs: Testcontainers](https://testcontainers.com/)
  Disposable, programmatically-managed containers as a test dependency — the standard answer
  to "each worker needs its own database".
  Use for: costing out the hermetic alternative to eight workers sharing one reset database.
  Read it as a price tag, not a recommendation.

## Knowledge — Playwright, the mechanism

- [Docs: Playwright — Auto-waiting / Actionability](https://playwright.dev/docs/actionability)
  The exact per-action check list: attached, visible, stable, receives events, enabled,
  editable — and which actions run which checks. The **hit target** check is the one that
  explains most mysterious canvas and overlay failures.
  Use for: reading a timeout failure precisely — *which* actionability check never passed —
  instead of retrying. Essential background for the editor's Moveable/Selecto overlays.

- [Docs: Playwright — Best Practices](https://playwright.dev/docs/best-practices)
  The official position: test user-visible behaviour, isolate tests, web-first assertions,
  no manual waits, use locators over handles.
  Use for: the baseline the Flowbase conventions already exceed in some places and
  deliberately diverge from in others. Read it to know which is which.

- [Docs: Playwright — Locators](https://playwright.dev/docs/locators) and
  [Other locators](https://playwright.dev/docs/other-locators)
  Reference for the locator priority Playwright recommends, `data-testid` configuration,
  strictness, filtering and chaining.
  Use for: the strictness rules (a locator resolving to two elements is an error, not a
  first-match) and for `testIdAttribute` when a `data-test-*` convention diverges.

- [Docs: Playwright — Clock](https://playwright.dev/docs/clock)
  `install`, `setFixedTime`, `setSystemTime`, `fastForward`, `pauseAt`, `runFor` — control of
  `Date`, `setTimeout`, `setInterval`, `requestAnimationFrame` and `performance.now`.
  Use for: the single largest untouched determinism lever in the suite — zero uses today —
  and for anything touching keyframes, animation playback, debounce, or TanStack `staleTime`.
  Read the caveat about `requestAnimationFrame` before applying it to canvas gestures.

- [Docs: Playwright — Network](https://playwright.dev/docs/network) and
  [Mock APIs](https://playwright.dev/docs/mock)
  `page.route`, `route.fulfill`, `route.abort`, `route.fallback`, HAR recording and replay,
  and `page.routeFromHAR`.
  Use for: the second untouched lever — provoking loading states, 500s, timeouts and
  offline behaviour that a healthy real backend will never produce on demand. HAR replay is
  the interesting option for the read-only pages that dominate CI time.

- [Docs: Playwright — Fixtures](https://playwright.dev/docs/test-fixtures)
  Test- and worker-scoped fixtures, `auto`, override and composition, and the setup/teardown
  ordering that makes auto fixtures tear down last.
  Use for: the ordering rule behind the "never delete the root of a cascade while the page is
  mounted" convention, and for worker-scoped data isolation.

- [Docs: Playwright — Parallelism](https://playwright.dev/docs/test-parallel) and
  [Sharding](https://playwright.dev/docs/test-sharding)
  Worker processes, `fullyParallel`, `describe.configure({ mode })`, `workers`, and
  `--shard` with report merging.
  Use for: the CI wall-clock work. Sharding is the lever Flowbase is not pulling; the
  project-dependency graph is what constrains how far it goes.

- [Docs: Playwright — Retries](https://playwright.dev/docs/test-retries)
  Retries, `flaky` as a distinct outcome in the report, and per-retry `testInfo.retry`.
  Use for: reading the flake data the current config already produces, and for the
  argument about what `retries: 3` is buying and hiding.

- [Docs: Playwright — Trace Viewer](https://playwright.dev/docs/trace-viewer)
  Action timeline, before/after/action DOM snapshots, network, console, source.
  Use for: the diagnosis workflow. `trace: 'retain-on-failure'` is already set, so this is
  a skill gap rather than a config gap.

- [Docs: Playwright — Global setup and teardown](https://playwright.dev/docs/test-global-setup-teardown),
  [Web server](https://playwright.dev/docs/test-webserver),
  [API testing](https://playwright.dev/docs/api-testing)
  Project dependencies vs `globalSetup`, `reuseExistingServer`, and `request` contexts for
  seeding state without a browser.
  Use for: the seeding architecture — the `*-seed` projects and `api-helpers/` are an
  instance of these primitives, and the tradeoffs are documented here.

- [Docs: Playwright — Component testing (experimental)](https://playwright.dev/docs/test-components)
  Mount a component in a real browser, with the explicit experimental caveat.
  Use for: an honest read on the missing level — real browser, real events, no backend —
  including why its experimental status might rule it out.

- [Docs: Playwright — ARIA snapshots](https://playwright.dev/docs/aria-snapshots)
  Assert a subtree's accessibility tree as YAML: structural snapshotting without pixels.
  Use for: the middle path between "assert one attribute" and "screenshot the canvas",
  for things like layer trees and property panels.

- [Docs: Playwright — Annotations](https://playwright.dev/docs/test-annotations)
  `test.skip`, `fixme`, `fail`, `slow`, and tags.
  Use for: the difference between `fail` and `fixme` — which is exactly the distinction the
  `@known-behavior` tag is currently hand-rolling.

## Knowledge — the TanStack Query layer

- [Docs: TanStack Query — Testing](https://tanstack.com/query/latest/docs/framework/react/guides/testing)
  The official guide: `retry: false`, `gcTime`, a fresh `QueryClient` per test, and silencing
  the logger.
  Use for: what a *component-level* query test needs. Note the framing — every hazard on this
  page is a determinism hazard, and each one has an E2E analogue.

- [Docs: TanStack Query — Important Defaults](https://tanstack.com/query/latest/docs/framework/react/guides/important-defaults)
  `staleTime: 0`, three retries with exponential backoff, `refetchOnWindowFocus`,
  `refetchOnMount`, `refetchOnReconnect`, structural sharing, garbage collection at 5 minutes.
  Use for: the list of behaviours that make a browser test nondeterministic *by default*.
  `refetchOnWindowFocus` alone can fire a request mid-assertion; the `app-idle` guard is
  currently absorbing that rather than removing it.

- [Docs: TanStack Query — Query Invalidation](https://tanstack.com/query/latest/docs/framework/react/guides/query-invalidation)
  and [Optimistic Updates](https://tanstack.com/query/latest/docs/framework/react/guides/optimistic-updates)
  Invalidation as "mark stale + refetch active", predicate matching on query keys, and the
  two optimistic-update strategies (cache write vs. `variables`), including the
  cancel → snapshot → apply → rollback sequence.
  Use for: naming the failure modes worth writing tests for — a mutation whose invalidation
  misses a key, and a rollback that never happens. These are the bugs a manually-handled
  cache actually ships.

## Knowledge — the canvas editor

- [Article: "Keeping Figma Fast" — Figma (2020)](https://www.figma.com/blog/keeping-figma-fast/)
  How the closest comparable product tests its editor: in-browser with a real GPU rather than
  headless, because the bugs they cared about were WebGL, browser layout and hook misuse — and
  parallelism, not test selection, is how they hold a ten-minute feedback loop.
  Use for: the prior-art argument that behaviour-level editor testing in a real browser is the
  right call, and the honest cost of it.

- [Article: "Figma Rendering: Powered by WebGPU" — Figma (2025)](https://www.figma.com/blog/figma-rendering-powered-by-webgpu/)
  Secondary, but it describes validating a full renderer swap against a baseline — a
  metamorphic-style comparison rather than golden images.
  Use for: how to gain confidence in a rendering change when pixel snapshots are off the table.

- [Docs: MDN — Pointer events and `setPointerCapture`](https://developer.mozilla.org/en-US/docs/Web/API/Element/setPointerCapture)
  The substrate under Gesto/Selecto/Moveable: capture semantics, coalesced events, and why a
  synthetic `mousemove` sequence that skips frames drops a drag.
  Use for: understanding *why* `dragBetween` has to step across rAFs, well enough to debug it
  rather than trust it.

## Knowledge — proving a test has power

- [Docs: StrykerJS — Mutation testing for JavaScript and TypeScript](https://stryker-mutator.io/docs/stryker-js/introduction/)
  Mutators, killed/survived/timeout/no-coverage outcomes, the mutation score, and the
  incremental mode that makes it affordable on a large codebase.
  Use for: the only honest answer to "does this test do anything?" Realistically applies to
  the pure `src/lib` and `e2e/lib` units first; a full-suite mutation run against E2E tests is
  not affordable, and knowing why is part of the lesson.

## Gaps

- **No high-trust source on parallel test isolation against one shared relational
  database.** The literature assumes hermetic per-test environments; Flowbase resets the
  database once per Playwright invocation and runs eight workers against it. The best
  available substitutes are the iDFlakies polluter/victim vocabulary applied to rows instead
  of static fields, and the suite's own conventions (`e2e/CLAUDE.md` teardown rules,
  fresh-user-per-spec in `sessions.spec.ts`, `language.spec.ts`, `profile.spec.ts`) read as
  worked examples. Worth a targeted search before building a lesson on it.

- **No written-up design of canvas/vector-editor *behaviour* testing.** Everything findable
  is either visual-regression tooling marketing or Figma's performance work. Transform maths,
  snapping, selection semantics and keyframes appear to have no public prior art — the
  `e2e/tests/editor/transform` specs are likely as good as anything published, which means
  lessons here derive from first principles plus the geometry.

- **No source found on Sentry as a test-flakiness sink.** Flowbase measures flake rate in
  Sentry, but a grep of the repo turns up only product-error wiring (`sentry-filters`,
  `third-party-telemetry`), not a CI → Sentry test-result pipeline. Either the pipeline lives
  outside this repo or the measurement is of a different quantity. Worth resolving before the
  measurement lesson, since the Kowalczyk score needs per-spec outcome history and
  Playwright's JSON reporter is the obvious place it comes from.

- **No good source on quantifying the value of a flake fix.** Google and Spotify publish
  flake *rates* and quarantine mechanics, but nothing found puts a number on "this fix bought
  us X". Needed for the "cut CI time and flake rate" half of the mission.

- **Nothing found on test-suite design for a monorepo with generated API clients** — the
  contract-drift question that `@/generated` types are answering. Consumer-driven contract
  testing (Pact) is adjacent literature but assumes hand-written clients; worth a search.