FL

flutter-testing

Automates the creation of Flutter tests including unit logic, widget UI interaction, and device integration.

Install

mkdir -p .claude/skills/flutter-testing && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/18503" && unzip -o skill.zip -d .claude/skills/flutter-testing && rm skill.zip

Installs to .claude/skills/flutter-testing

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Add Flutter unit tests, widget tests, or integration tests
58 charsno explicit “when” trigger
Intermediate

Key capabilities

  • Determine appropriate test type (Unit, Widget, Integration, Plugin)
  • Implement Unit Tests for logic and architecture
  • Implement Widget Tests for UI components
  • Implement Integration Tests for end-to-end app behavior
  • Implement Plugin Tests for platform-specific native code
  • Validate and fix tests based on user-provided output

How it works

This skill generates, configures, and debugs automated tests for Flutter applications by determining the appropriate test type based on the target code and providing boilerplate.

Inputs & outputs

You give it
Flutter target code (function, ViewModel, widget, app flow, plugin)
You get back
Generated and configured automated tests (unit, widget, integration, or plugin) and debugging assistance

When to use flutter-testing

  • Adding unit tests for ViewModels
  • Creating widget tests for UI elements
  • Implementing end-to-end integration tests

About this skill

flutter-automated-testing

Goal

Generates, configures, and debugs automated tests for Flutter applications, encompassing unit, widget, integration, and plugin testing. Analyzes architectural components (such as MVVM layers) to produce isolated, mock-driven tests and end-to-end device tests. Assumes a standard Flutter project structure, existing business logic, and familiarity with Dart testing paradigms.

Instructions

1. Determine Test Type (Decision Logic)

Evaluate the user's target code to determine the appropriate testing strategy using the following decision tree:

  • If verifying a single function, method, ViewModel, or Repository: Implement a Unit Test (Proceed to Step 2).
  • If verifying a single widget's UI, layout, or interaction: Implement a Widget Test (Proceed to Step 3).
  • If verifying complete app behavior, routing, or performance on a device: Implement an Integration Test (Proceed to Step 4).
  • If verifying platform-specific native code (MethodChannels): Implement a Plugin Test (Proceed to Step 5).

STOP AND ASK THE USER: "Which specific class, widget, or flow are we testing today? Please provide the relevant source code if you haven't already."

2. Implement Unit Tests (Logic & Architecture)

Unit tests verify logic without rendering UI. They must reside in the test/ directory and end with _test.dart.

  • For ViewModels (UI Layer Logic): Fake the repository dependencies. Do not rely on Flutter UI libraries.
import 'package:test/test.dart';
// Import your ViewModel and Fakes here

void main() {
  group('HomeViewModel tests', () {
    test('Load bookings successfully', () {
      final viewModel = HomeViewModel(
        bookingRepository: FakeBookingRepository()..createBooking(kBooking),
        userRepository: FakeUserRepository(),
      );

      expect(viewModel.bookings.isNotEmpty, true);
    });
  });
}
  • For Repositories (Data Layer Logic): Fake the API clients or local database services.
import 'package:test/test.dart';
// Import your Repository and Fakes here

void main() {
  group('BookingRepositoryRemote tests', () {
    late BookingRepository bookingRepository;
    late FakeApiClient fakeApiClient;

    setUp(() {
      fakeApiClient = FakeApiClient();
      bookingRepository = BookingRepositoryRemote(apiClient: fakeApiClient);
    });

    test('should get booking', () async {
      final result = await bookingRepository.getBooking(0);
      final booking = result.asOk.value;
      expect(booking, kBooking);
    });
  });
}

3. Implement Widget Tests (UI Components)

Widget tests verify UI rendering and interaction. They must reside in the test/ directory and use the flutter_test package.

  • Use WidgetTester to build the widget.
  • Use Finder to locate elements (find.text(), find.byKey(), find.byWidget()).
  • Use Matcher to verify existence (findsOneWidget, findsNothing, findsNWidgets).
import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';

void main() {
  testWidgets('HomeScreen displays title and handles tap', (WidgetTester tester) async {
    // 1. Setup Fakes and ViewModel
    final bookingRepository = FakeBookingRepository()..createBooking(kBooking);
    final viewModel = HomeViewModel(
      bookingRepository: bookingRepository,
      userRepository: FakeUserRepository(),
    );

    // 2. Build the Widget tree
    await tester.pumpWidget(
      MaterialApp(
        home: HomeScreen(viewModel: viewModel),
      ),
    );

    // 3. Finders
    final titleFinder = find.text('Home');
    final buttonFinder = find.byKey(const Key('increment_button'));

    // 4. Assertions
    expect(titleFinder, findsOneWidget);

    // 5. Interactions
    await tester.tap(buttonFinder);
    await tester.pumpAndSettle(); // Wait for animations/state updates to finish

    expect(find.text('1'), findsOneWidget);
  });
}

4. Implement Integration Tests (End-to-End)

Integration tests run on real devices or emulators. They must reside in the integration_test/ directory.

  • Ensure integration_test is in dev_dependencies in pubspec.yaml.
  • Initialize IntegrationTestWidgetsFlutterBinding.
import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:integration_test/integration_test.dart';
import 'package:my_app/main.dart' as app;

void main() {
  IntegrationTestWidgetsFlutterBinding.ensureInitialized();

  group('End-to-End App Test', () {
    testWidgets('Full flow: tap FAB and verify counter', (WidgetTester tester) async {
      // Load the full app
      app.main();
      await tester.pumpAndSettle();

      // Verify initial state
      expect(find.text('0'), findsOneWidget);

      // Find and tap the FAB
      final fab = find.byKey(const ValueKey('increment'));
      await tester.tap(fab);
      
      // Trigger a frame
      await tester.pumpAndSettle();

      // Verify state change
      expect(find.text('1'), findsOneWidget);
    });
  });
}

5. Implement Plugin Tests (Native & Dart)

If testing a plugin, tests must cover both Dart and Native communication.

  • Dart Side: Mock the platform channel and call the plugin's public API.
  • Native Side: Instruct the user to write native tests in the respective directories:
    • Android: android/src/test/ (JUnit)
    • iOS/macOS: example/ios/RunnerTests/ (XCTest)
    • Linux/Windows: linux/test/ (GoogleTest)

6. Validate and Fix (Feedback Loop)

Provide the user with the exact command to run the generated test:

  • Unit/Widget: flutter test test/your_test_file.dart
  • Integration: flutter test integration_test/your_test_file.dart

STOP AND ASK THE USER: "Please run the test using the command above and paste the output. If the test fails, provide the stack trace so I can analyze the failure and generate a fix."

Constraints

  • Single Source of Truth: Do not duplicate state in tests. Always use fakes or mocks for external dependencies (Repositories, Services) to isolate the unit under test.
  • No Logic in Widgets: When writing widget tests, assume the widget is "dumb". All business logic should be tested via the ViewModel/Controller unit tests.
  • File Naming: All test files MUST end with _test.dart.
  • Pump vs PumpAndSettle: Use tester.pump() for single frame advances. Use tester.pumpAndSettle() strictly when waiting for animations or asynchronous UI updates to complete.
  • Immutability: Treat test data models as immutable. Create new instances for state changes rather than mutating existing mock data.
  • Do not use dart:mirrors: Flutter does not support reflection. Rely on code generation (e.g., build_runner, mockito, mocktail) for mocking.

When not to use it

  • When duplicating state in tests
  • When relying on Flutter UI libraries in ViewModels
  • When using `dart:mirrors` for mocking

Limitations

  • Assumes a standard Flutter project structure
  • Assumes existing business logic
  • Assumes familiarity with Dart testing paradigms

How it compares

This skill provides a decision-tree approach to Flutter testing, guiding the user to the correct test type and offering specific code examples for isolated, mock-driven tests, which is more structured than general testing advice.

Compared to similar skills

flutter-testing side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
flutter-testing (this skill)04moNo flagsIntermediate
flutter133moNo flagsIntermediate
flutter-bloc-state-management03moNo flagsIntermediate
flutter-development1,5554moNo flagsIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

Search skills

Search the agent skills registry