flutter-testing
Define testing strategy, test pyramid, and pattern-based conventions (Golden Variants, State Matrix, Interaction Contracts). Use when establishing test architecture or choosing the right testing approach for a Flutter project.
What this skill does
# Testing Strategy
- **Test Pyramid**: More unit and widget tests, fewer integration tests. Unit tests are fastest and cheapest.
- **Mirror Test Rule**: 100% logic and widget coverage. No code without a test.
- **Mirror Organization**: Test files MUST strictly mirror the `lib/` directory structure and end with `_test.dart`.
- **Coverage Targets**: Target 100% logic coverage for `domain` and `bloc` layers.
- **Test Independence**: Each test MUST be independent. No shared mutable state between tests.
# Test Types Overview
| Type | Scope | Speed | Skill |
|---|---|---|---|
| **Unit** | Single function/class | Fast | `dart-testing` |
| **Widget** | Single UI component | Medium | `flutter-add-widget-test` |
| **Integration** | Full app / user flow | Slow | `flutter-add-integration-test` |
# Pattern-Based Testing
These three patterns cut repetitive test setup, cover all visual states, and keep widget behavior consistent. They're conventions, not packages.
## Golden Variant Testing
When a widget has multiple visual states (primary, disabled, hover, error), test all variants in a single structured `group()` with a `Map<String, Widget Function()>`:
- Define a `variants` map where keys are state names and values are widget builders.
- Each variant MUST be rendered in isolation (fresh `pumpWidget` call per variant).
- Use deterministic golden file naming: `goldens/<component>.<variant>.png`.
- Set a consistent `surfaceSize` via `tester.view.physicalSize` to avoid flaky pixel diffs.
- **When to use**: Design system components, widgets with distinct modes/types.
- **When NOT to use**: Integration tests or animation frame verification.
## State Matrix Testing
Every stateful widget MUST be tested against ALL possible UI states. Use a state matrix to separate setup from verification:
- Define a `states` map with every state the widget can render (`loading`, `error`, `data`, `empty`).
- Write a single `verify(stateName)` callback that asserts correct rendering per state using `switch` expressions.
- This pattern prevents the common mistake of only testing the "happy path".
- **When to use**: Widgets with complex state machines (e.g., BLoC-driven screens).
- **When NOT to use**: If verification logic varies wildly between states, write separate tests.
## Interaction Contract Testing
Reusable widgets have implicit behavioral rules. Define these as explicit, reusable contracts:
- Create helper functions in `test/utils/` for common contracts:
- `verifyTappable(tester, finder, mockCallback)` — Tap fires callback exactly once.
- `verifyDisabledNotTappable(tester, finder, mockCallback)` — Tap does NOT fire callback when disabled.
- `verifyValidatesOnBlur(tester, finder)` — Validation triggers when focus leaves.
- Apply contracts consistently across all widgets sharing the same behavior.
- **When to use**: Widgets with strictly defined behavioral rules that must hold across refactors.
- **When NOT to use**: One-off logic unique to a single widget.
# Test Naming & Structure
- **Test Naming**: Use string interpolation for test group names: `group('$ClassName',` not `group('ClassName',`. This ensures consistency and enables better tooling support.
- **Test Grouping**: Use `group()` to organize tests by feature, class, or state for clearer reporting.
- **Descriptive Names**: Test names should clearly describe what is being tested and why.
# Common Test Errors
- `A RenderFlex overflowed...` — Wrap widget in `Expanded` or constrain dimensions in test
- `Vertical viewport was given unbounded height` — Wrap `ListView` in `SizedBox` with fixed height in test
- `setState called during build` — Defer state changes to post-frame callback
- `No MediaQuery widget ancestor` — Always wrap test widget in `MaterialApp`
# Running Tests (Quick Reference)
- `flutter test` — Run all unit and widget tests
- `flutter test test/path/to/file_test.dart` — Run specific test file
- `flutter test integration_test/` — Run integration tests
- `flutter test --coverage` — Run with coverage report
- `dart test` — Pure Dart unit tests
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.