flutter-testing

Flutter Testing

Writes unit, widget, golden, and integration tests that match this project's existing state-management, mocking, and directory conventions. Writing correct, well-structured test files is the deliverable. Running the suite and verifying it — including the fault-injection self-check — is a separate, optional step this skill offers but never runs without being asked. See Step 6.

Progress checklist

Copy this into your response and check items off as you go:

- [ ] 1. Detect stack (scripts/detect_stack.sh)
- [ ] 2. Audit project structure and existing test conventions
- [ ] 3. Ask the user what to test (layer + scope) — do not assume
- [ ] 4. State the test plan explicitly
- [ ] 5. Generate tests following AAA, boundary-only mocking
- [ ] 6. Report what was written; offer to run + verify — do not run yet
- [ ] 7. Only if asked: run tests, fault-injection self-check, report results

Step 1 — Detect stack

Run scripts/detect_stack.sh from the project root. It confirms this is a Flutter project and reports which state-management package, mocking library, golden-test helper, and Firebase fakes are already declared in pubspec.yaml, plus whether test/ already exists and mirrors lib/.

If a test framework or mocking library is already in use, follow it even if a different tool is this skill's default recommendation. Never introduce a second, competing library into a project that already picked one.

Step 2 — Audit project structure

Before writing anything:

• Classify the target code: pure business logic (services, repositories, use-cases) vs UI layer (widgets) vs data-access (Firebase, API clients) vs cross-cutting (routing, DI). This decides the test type — don't default to a widget test for logic that's dressed up inside a widget file; if the architecture allows extracting it into a plain testable class/function, say so in the plan (Step 4) rather than testing it in place.
• Confirm the state-management package via reference/state-management.md and select the matching harness pattern — never generate a BLoC-style test for a Riverpod provider or vice versa.
• Match the existing test/ naming convention exactly (does it mirror lib/ file-for-file already?). scripts/scaffold_test_file.sh creates a correctly-mirrored, non-destructive stub for a new test file if useful.
• Flag critical paths — authentication, payment/billing, any data-write operation, anything touching an external paid/rate-limited service — for elevated rigor (more edge cases; these are the tests where, if the user opts into verification in Step 7, the fault-injection check is mandatory rather than optional) even if the user's request was narrower. State this flag out loud; do not silently expand scope beyond what was asked.