In Flutter golden tests, how do you cover a receipt widget in light and dark themes and at larger text scales without duplicating tests?

## The problem A receipt card has to look right in several configurations: light theme, dark theme, and larger system text sizes where item names wrap and prices can overflow. Copy-pasting a golden test per combination multiplies code, and the copies drift apart. `flutter_test` gives you two tidy ways to run one test body several times. ## Option 1: `ValueVariant` `testWidgets` has a `variant` parameter of type `TestVariant<Object?>`. A **`ValueVariant<T>`** takes a `Set<T>` of values; for each value the framework: 1. calls the variant's `setUp`, which stores the value in `currentValue`; 2. runs the test body, whose name gets the value's description appended, so reports show which case failed; 3. calls `tearDown`. Inside the body, `variant.currentValue` tells you which configuration to build. Because each value becomes its own test run, failures are reported per case and each can be re-run by name. ## Option 2: a loop of `testWidgets` A `for` loop over a list of cases that calls `testWidgets` with an interpolated name works too and is sometimes clearer when each case needs a different setup. The key rule is the same: **one golden file per case**. ## Applying the theme Build the `MaterialApp` from the case: `theme: ThemeData(brightness: c.brightness)`. Alternatively pass both `theme` and `darkTheme` and set `themeMode` to `ThemeMode.light` or `ThemeMode.dark`. Either way the receipt reads its colours from `Theme.of(context)`, so both goldens exercise the real theme wiring instead of a hand-picked colour. ## Applying a text scale Two approaches: - **Platform override**: `tester.platformDispatcher.textScaleFactorTestValue = 2.0`, with `addTearDown(tester.platformDispatcher.clearTextScaleFactorTestValue)`. The `MediaQuery` that `MaterialApp` builds from the view picks it up, exactly as a user's system setting would reach the app. - **Widget override**: in `MaterialApp.builder`, wrap `child` in a `MediaQuery` whose data is `MediaQuery.of(context).copyWith(textScaler: TextScaler.linear(2.0))`. The platform override tests the path from system setting to app, including any clamping the app applies; the widget override is more local and explicit. Either one must be undone so it does not leak into the next test. ## Naming and sizing | Case | Golden file | |---|---| | light, 1.0 | `goldens/receipt_light_x1.png` | | dark, 1.0 | `goldens/receipt_dark_x1.png` | | light, 2.0 | `goldens/receipt_light_x2.png` | | dark, 2.0 | `goldens/receipt_dark_x2.png` | - Put the case in the file name, never reuse one name across cases. - Keep the view size fixed for all cases (`tester.view.physicalSize`, reset with `addTearDown(tester.view.reset)`) so the only variable is the one you meant. - Capture a keyed `RepaintBoundary` around the receipt so larger text that grows the card grows the image, and a clipped total becomes visible. ## Choosing the matrix Every case is another baseline to regenerate and review whenever the receipt changes. A good default is light and dark at the normal scale plus one large scale (2.0 is a common choice) in one theme; add more only where a bug has already appeared. Overflow at large text is often better asserted with a plain widget test as well - `tester.takeException()` returning a `FlutterError` about overflow - so the failure message names the problem instead of showing only a diff. ## What the goldens will and will not show - **Will show**: wrapping and overflow at larger text, contrast problems in dark theme, a colour hard-coded instead of read from the theme. - **Will not show**: whether the real font looks right (unless fonts are loaded), or whether a screen reader announces the total - that needs semantics checks, not pixels.