Flutter Testing Standards skill
Write unit, widget, and integration tests with robot patterns, widget keys, and Patrol in Flutter.
by HoangNguyen0403·MIT license·★ 569 Stars on the repo·GitHub ↗
Use now
npx degit HoangNguyen0403/agent-skills-standard/skills/flutter/flutter-testing#develop ~/.claude/skills/flutter-testingChecked ·commit develop
Files of Flutter Testing Standards
SKILL.md
Show the full text81 lines
Flutter Testing Standards
Priority: P0 (CRITICAL)
The Four-Pillar Test Value Framework
The Four Pillars provide a qualitative reasoning framework to assess test value:
- Protection against Regressions ($P$): Catches real defects; evaluated qualitatively or via mutation kill score. A test that passes when defects exist has zero protection.
- Resistance to Refactoring ($R$): Decoupled from implementation details; zero false alarms on internal refactorings or domain additions. Tests coupled to private state or mock sequences score low on resistance.
- Fast Feedback ($F$): Executes in milliseconds; rapid local TDD feedback loop.
- Maintainability ($M$): Clean AAA structure, fluent test data builders when setup repetition obscures intent, high readability, zero boilerplate duplication.
Avoid calculating or inventing arbitrary numeric scores (e.g. $P \times R \times F \times M$) statically without measured mutation or runtime evidence.
Core Rule Anchors
[MOB-TEST-01]Tripartite Naming: Name testsMethod_Scenario_ExpectedBehavior.[MOB-TEST-02]BLoC State Invariant Rule: Assert state transitions usingisA<State>().having(...)predicates; BAN full copyWith mirrors.[MOB-TEST-03]Entity Invariant & Serialization Rule: Test calculations, validations, domain invariants, and non-trivial serialization/parsing or error mapping. BAN testing generated code, trivial getters/setters,props, or echo tests (expect(item.discount, equals(5))) where the test merely repeats literal assignments.[MOB-TEST-04]Contract Testing Rule: Repositories and data sources must be tested for contract compliance, golden JSON parsing, and error mapping. BAN 1:1 pass-through mock echoing (when(() => dataSource.get()).thenAnswer((_) async => x); expect(await repo.get(), x)).[MOB-TEST-05]Bug-First Regression Lock: Every PR fixing a bug ticket or with titlefix(...)must introduce a failing test reproducing the defect before fixing it.
Core Rules
- Test Pyramid: Unit > Widget > Integration.
- Naming: Follow
[MOB-TEST-01](Method_Scenario_ExpectedBehavior). - AAA: Arrange, Act, Assert in all tests.
- Isolated Builders: Fluent builders when setup complexity warrants (
OrderBuilder); avoid brittle shared global mocks. - File Placement:
_integration_test.dartONLY inintegration_test/. - Robot-First: All UI assertions/interactions via Robot pattern (extending
BaseRobot) — never rawfind.*/expect()in test body. UseWidgetKeysconstants fromlib/core/keys/. - Negative Assertions: Add
expectXxxNotVisible()in robot only when absence is part of the business contract (e.g. restricted action hidden), not blanket pairs for unrelated content. - Widget Testing & Mocking: Setup with
TestWrapper.init()andtester.pumpLocalizedWidget(...). Register mock BLoCs withGetItinsetUpAll; stubstateandstreaminsetUp(usewhenListenandsettle: falsefor loading/transition states). Prohibitany(). - Integration Testing: Use
patrolTestwithIntegrationAuthHelper.loginOrSkip($)for auth flows andnative interactions($.native.*).
Anti-Patterns & Banned Smells
[MOB-TEST-01]Vague names: Banish non-descriptive names (testCart).[MOB-TEST-02]Brittle state mirrors: Ban 30-propertycopyWithtrees inblocTest; useisA<State>().having(...).[MOB-TEST-03]Entity echo tests: Ban asserting trivial field assignments or auto-generated boilerplate (discount: 5). Meaningful serialization/parsing error handling remains valid.[MOB-TEST-04]Pass-through mock echoing: Ban 1:1 repository-to-datasource pass-through mocks without contract assertions.[MOB-TEST-05]Missing bug reproduction: Ban bug fix PRs without reproduction tests.- No blanket negative assertions: Avoid asserting absence of unrelated content.
- No inline Key: Use
WidgetKeysconstant. Noany(): Use typed matchers. - No local mocks: Use
test/shared/. No missing bloc stub: Stubstate+stream. - No test-body logic: Move
find.*/expect()to robot. No raw find in integration tests. - No unchecked text casing: Verify
.toUpperCase(),.tr()in source.
Verification
- Repositories use fakes over mocks where appropriate.
- Distinct BLoC/ViewModel behaviors covered (loading, success, error) with
isA<State>().having(...). - Views with distinct UI logic tested via Robot pattern at proper layer.
- Critical user flows have at least one integration test using
patrolTest. -
flutter testpasses.
Canonical response anchors
When this skill applies, preserve the following domain terminology or equivalent concrete examples in the answer when relevant:
- GetIt registration
- Register the mock with
GetItinsetUpAllbefore building the widget under test. - native interactions
| 1 | |
| 2 | name flutter-testing |
| 3 | description Write unit, widget, and integration tests with robot patterns, widget keys, and Patrol in Flutter. Use when implementing test behavior; defer CI-only configuration without test changes. |
| 4 | metadata |
| 5 | triggers |
| 6 | files |
| 7 | - '**/test/**.dart' |
| 8 | - '**/integration_test/**.dart' |
| 9 | - '**/robots/**.dart' |
| 10 | - 'lib/core/keys/**.dart' |
| 11 | keywords |
| 12 | - test |
| 13 | - patrol |
| 14 | - robot |
| 15 | - WidgetKeys |
| 16 | - patrolTest |
| 17 | - blocTest |
| 18 | - mocktail |
| 19 | |
| 20 | # Flutter Testing Standards |
| 21 | |
| 22 | ## **Priority: P0 (CRITICAL)** |
| 23 | |
| 24 | ## The Four-Pillar Test Value Framework |
| 25 | |
| 26 | The Four Pillars provide a qualitative reasoning framework to assess test value: |
| 27 | **Protection against Regressions ($P$)**: Catches real defects; evaluated qualitatively or via mutation kill score. A test that passes when defects exist has zero protection. |
| 28 | **Resistance to Refactoring ($R$)**: Decoupled from implementation details; zero false alarms on internal refactorings or domain additions. Tests coupled to private state or mock sequences score low on resistance. |
| 29 | **Fast Feedback ($F$)**: Executes in milliseconds; rapid local TDD feedback loop. |
| 30 | **Maintainability ($M$)**: Clean AAA structure, fluent test data builders when setup repetition obscures intent, high readability, zero boilerplate duplication. |
| 31 | |
| 32 | Avoid calculating or inventing arbitrary numeric scores (e.g. $P \times R \times F \times M$) statically without measured mutation or runtime evidence. |
| 33 | |
| 34 | ## Core Rule Anchors |
| 35 | |
| 36 | **`[MOB-TEST-01]` Tripartite Naming**: Name tests `Method_Scenario_ExpectedBehavior`. |
| 37 | **`[MOB-TEST-02]` BLoC State Invariant Rule**: Assert state transitions using `isA<State>().having(...)` predicates; BAN full copyWith mirrors. |
| 38 | **`[MOB-TEST-03]` Entity Invariant & Serialization Rule**: Test calculations, validations, domain invariants, and non-trivial serialization/parsing or error mapping. BAN testing generated code, trivial getters/setters, `props`, or echo tests (`expect(item.discount, equals(5))`) where the test merely repeats literal assignments. |
| 39 | **`[MOB-TEST-04]` Contract Testing Rule**: Repositories and data sources must be tested for contract compliance, golden JSON parsing, and error mapping. BAN 1:1 pass-through mock echoing (`when(() => dataSource.get()).thenAnswer((_) async => x); expect(await repo.get(), x)`). |
| 40 | **`[MOB-TEST-05]` Bug-First Regression Lock**: Every PR fixing a bug ticket or with title `fix(...)` must introduce a failing test reproducing the defect before fixing it. |
| 41 | |
| 42 | ## Core Rules |
| 43 | |
| 44 | **Test Pyramid**: Unit > Widget > Integration. |
| 45 | **Naming**: Follow `[MOB-TEST-01]` (`Method_Scenario_ExpectedBehavior`). |
| 46 | **AAA**: Arrange, Act, Assert in all tests. |
| 47 | **Isolated Builders**: Fluent builders when setup complexity warrants (`OrderBuilder`); avoid brittle shared global mocks. |
| 48 | **File Placement**: `_integration_test.dart` ONLY in `integration_test/`. |
| 49 | **Robot-First**: All UI assertions/interactions via **Robot pattern** (extending `BaseRobot`) — never raw `find.*`/`expect()` in test body. Use `WidgetKeys` constants from `lib/core/keys/`. |
| 50 | **Negative Assertions**: Add `expectXxxNotVisible()` in robot only when absence is part of the business contract (e.g. restricted action hidden), not blanket pairs for unrelated content. |
| 51 | **Widget Testing & Mocking**: Setup with `TestWrapper.init()` and `tester.pumpLocalizedWidget(...)`. Register mock BLoCs with `GetIt` in `setUpAll`; stub `state` and `stream` in `setUp` (use `whenListen` and `settle: false` for loading/transition states). Prohibit `any()`. |
| 52 | **Integration Testing**: Use `patrolTest` with `IntegrationAuthHelper.loginOrSkip($)` for auth flows and `native interactions` (`$.native.*`). |
| 53 | |
| 54 | ## Anti-Patterns & Banned Smells |
| 55 | |
| 56 | **`[MOB-TEST-01]` Vague names**: Banish non-descriptive names (`testCart`). |
| 57 | **`[MOB-TEST-02]` Brittle state mirrors**: Ban 30-property `copyWith` trees in `blocTest`; use `isA<State>().having(...)`. |
| 58 | **`[MOB-TEST-03]` Entity echo tests**: Ban asserting trivial field assignments or auto-generated boilerplate (`discount: 5`). Meaningful serialization/parsing error handling remains valid. |
| 59 | **`[MOB-TEST-04]` Pass-through mock echoing**: Ban 1:1 repository-to-datasource pass-through mocks without contract assertions. |
| 60 | **`[MOB-TEST-05]` Missing bug reproduction**: Ban bug fix PRs without reproduction tests. |
| 61 | **No blanket negative assertions**: Avoid asserting absence of unrelated content. |
| 62 | **No inline Key**: Use `WidgetKeys` constant. **No `any()`**: Use typed matchers. |
| 63 | **No local mocks**: Use `test/shared/`. **No missing bloc stub**: Stub `state` + `stream`. |
| 64 | **No test-body logic**: Move `find.*`/`expect()` to robot. No raw find in integration tests. |
| 65 | **No unchecked text casing**: Verify `.toUpperCase()`, `.tr()` in source. |
| 66 | |
| 67 | ## Verification |
| 68 | |
| 69 | [ ] Repositories use fakes over mocks where appropriate. |
| 70 | [ ] Distinct BLoC/ViewModel behaviors covered (loading, success, error) with `isA<State>().having(...)`. |
| 71 | [ ] Views with distinct UI logic tested via Robot pattern at proper layer. |
| 72 | [ ] Critical user flows have at least one integration test using `patrolTest`. |
| 73 | [ ] `flutter test` passes. |
| 74 | |
| 75 | ## Canonical response anchors |
| 76 | |
| 77 | When this skill applies, preserve the following domain terminology or equivalent concrete examples in the answer when relevant: |
| 78 | GetIt registration |
| 79 | Register the mock with `GetIt` in `setUpAll` before building the widget under test. |
| 80 | native interactions |
| 81 |
Discussion
Alternatives
`expo-overview` — router & shared rules for Expo / EASEntry point and router for every Expo or EAS task. Load this skill first — before writing code and before choosing another expo-* / eas-* skill — when the request, PRD, or spec mentions Expo, EAS, Expo Go, or an expo-* package, or the project has an `expo` dependency in `package.json`. Within that gate it also covers app specs and designs to implement (tabs, stacks, maps, lists, navigation, building from a screenshot), and phrasings like 'implement a mobile app', 'make my app look native', 'add navigation', 'fetch some data', 'upgrade my SDK', 'add Expo to my existing native app', 'ship to the App Store', or 'I'm new to Expo, where do I start'. A fully specified request (SDK pinned, libraries named, layout given) still routes through here — the shared setup rules still apply. Do NOT load it when neither signal is present: a bare React Native project with no `expo` dependency is not Expo work. Detects the real goal, routes to the right expo-* / eas-* skill, and owns the shared setup rules.Add an App Clip to an Expo AppAdd an iOS App Clip target to an Expo app. Use when the user mentions App Clip, AASA, apple-app-site-association, appclips, smart app banner, or wants to ship a lightweight iOS Clip invoked from a URL alongside their parent app.App Store DeploymentBuild and submit iOS and Android apps with EAS to TestFlight, the App Store, or Google Play. Supports Expo and other React Native projects, plus existing native apps. Use for eas.json setup, release pipelines, signing, app versions and build numbers, store submissions, and listing metadata. For Expo websites and API routes, use eas-hosting; for adding React Native screens to a native app, use expo-brownfield.Designing with SleekUse when the user wants to design a mobile app or UI screens, when they mention their Sleek (sleek.design) projects, or when implementing Sleek designs in code (HTML, React Native, SwiftUI).
Browse more free Claude skills or everything in Development.