| name | flutter-testing |
| description | Writes unit, widget, golden, and integration tests for Flutter projects, detecting whether BLoC, Riverpod, Provider, or GetX is in use from pubspec.yaml before writing any business-logic test. Use when the user asks to write Flutter tests, add test coverage to a widget/bloc/provider/repository, test a .dart file, or mentions pubspec.yaml, flutter_test, mocktail, bloc_test, integration_test, or golden tests. |
| license | MIT |
| compatibility | Requires the Flutter SDK (flutter command) available on PATH for stack detection and optional test execution. Requires a pubspec.yaml declaring a flutter sdk dependency. |
| metadata | {"platform":"flutter","report-source":"testing-methodologies-deep-research-report.txt Part 2 and Part 8"} |
| allowed-tools | Read, Write, Edit, Grep, Glob, Bash |
| paths | ["**/*.dart","pubspec.yaml"] |
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.
