Testing Flutter Apps: Unit, Widget, and Integration Testing

Quality Assurance: Mastering the Testing Pyramid in Flutter

In the fast-paced world of mobile product development, shipping features quickly is only half the battle. The true differentiator for premium digital products is long-term stability, regression resistance, and a flawless user experience. Welcome to the ultimate testing flutter apps guide. Whether you are building a high-performance fintech dashboard or a consumer-facing e-commerce platform, establishing a rigorous automated testing strategy is non-negotiable.

When leveraging the power of cross-platform development, engineering teams often worry about maintaining native-grade quality across multiple operating systems. If you are still deciding on your technology stack, check out our comprehensive analysis on why Flutter is the ultimate cross-platform framework to understand how its architectural design simplifies rendering and state management. As we will explore in this testing flutter apps guide, Flutter's architecture also provides an incredibly powerful, unified testing framework that spans the entire testing pyramid.

       /\
      /  \      Integration Tests (High Fidelity, Slow, Real Devices)
     /----\
    /      \    Widget Tests (Medium Fidelity, Fast, Headless UI)
   /--------\
  /          \  Unit Tests (Low Fidelity, Ultra-Fast, Business Logic)
 /____________\

The testing pyramid is a conceptual framework that guides how you should distribute your testing efforts:

Unit Tests: Focus on isolated blocks of code—such as functions, methods, and state managers—without external dependencies. They are extremely fast and cheap to run.
Widget Tests: Also known as component tests in other ecosystems. They isolate individual UI components or screens, rendering them in a headless test environment to verify layout, rendering, and user interactions without the overhead of an emulator.
Integration Tests: Run the entire application on a real device or emulator, testing end-to-end user journeys, network communication, and native platform integrations.

By balancing these three layers, you can build a highly resilient test suite that catches bugs early in the development lifecycle, minimizes manual QA overhead, and accelerates your release velocity.

Unit Testing Dart Code: Mocking Dependencies with Mockito/Mocktail

Unit tests form the foundation of your testing suite. Writing robust unit tests dart developers can rely on requires isolating your business logic from external dependencies like REST APIs, local databases, and native device sensors.

In Dart, we achieve this isolation through dependency injection and mocking. While mockito has historically been the standard, mocktail has emerged as a modern, developer-friendly alternative that leverages Dart's strong null-safety features without requiring code generation.

Let's look at a real-world scenario: testing a UserRepository that depends on an ApiClient to fetch user profiles.

Step 1: Define the Domain Model and Service Interface

First, we define our data model and the API client interface.

// lib/models/user.dart
class User {
  final String id;
  final String name;
  final String email;
 
  User({required this.id, required this.name, required this.email});
 
  factory User.fromJson(Map<String, dynamic> json) {
    return User(
      id: json['id'] as String,
      name: json['name'] as String,
      email: json['email'] as String,
    );
  }
}
 
// lib/services/api_client.dart
import 'package:http/http.dart' as http;
 
class ApiClient {
  final http.Client httpClient;
  final String baseUrl;
 
  ApiClient({required this.httpClient, required this.baseUrl});
 
  Future<Map<String, dynamic>> get(String path) async {
    final response = await httpClient.get(Uri.parse('$baseUrl$path'));
    if (response.statusCode == 200) {
      return Map<String, dynamic>.from(
        Uri.decodeComponent(response.body) as Map,
      );
    } else {
      throw Exception('Network Error: ${response.statusCode}');
    }
  }
}

Step 2: Implement the Repository with Dependency Injection

We inject the ApiClient into our repository. This design pattern is crucial for testability.

// lib/repositories/user_repository.dart
import 'package:my_app/models/user.dart';
import 'package:my_app/services/api_client.dart';
 
class UserRepository {
  final ApiClient apiClient;
 
  UserRepository({required this.apiClient});
 
  Future<User> getUserProfile(String userId) async {
    try {
      final data = await apiClient.get('/users/$userId');
      return User.fromJson(data);
    } catch (e) {
      throw Exception('Failed to fetch user profile: $e');
    }
  }
}

Step 3: Write the Unit Test with Mocktail

Now, we write our unit tests. We will mock the ApiClient to simulate both successful API responses and network failures.

// test/unit/user_repository_test.dart
import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';
import 'package:my_app/models/user.dart';
import 'package:my_app/services/api_client.dart';
import 'package:my_app/repositories/user_repository.dart';
 
// Create a mock class by extending Mock and implementing the target class
class MockApiClient extends Mock implements ApiClient {}
 
void main() {
  late MockApiClient mockApiClient;
  late UserRepository userRepository;
 
  setUp(() {
    mockApiClient = MockApiClient();
    userRepository = UserRepository(apiClient: mockApiClient);
  });
 
  group('UserRepository - getUserProfile', () {
    const userId = 'usr_12345';
    const mockUserJson = {
      'id': 'usr_12345',
      'name': 'Jane Doe',
      'email': 'jane.doe@vyrova.tech',
    };
 
    test('should return a User model when the API call is successful', () async {
      // Arrange: Stub the mock API client to return a successful response
      when(() => mockApiClient.get('/users/$userId'))
          .thenAnswer((_) async => mockUserJson);
 
      // Act: Call the repository method
      final result = await userRepository.getUserProfile(userId);
 
      // Assert: Verify the results and interactions
      expect(result, isA<User>());
      expect(result.id, equals('usr_12345'));
      expect(result.name, equals('Jane Doe'));
      expect(result.email, equals('jane.doe@vyrova.tech'));
      
      // Verify that the API client was called exactly once with the correct path
      verify(() => mockApiClient.get('/users/$userId')).called(1);
    });
 
    test('should throw an exception when the API call fails', () async {
      // Arrange: Stub the mock API client to throw an exception
      when(() => mockApiClient.get('/users/$userId'))
          .thenThrow(Exception('Internal Server Error'));
 
      // Act & Assert: Verify that the repository propagates the exception
      expect(
        () => userRepository.getUserProfile(userId),
        throwsA(isA<Exception>()),
      );
 
      verify(() => mockApiClient.get('/users/$userId')).called(1);
    });
  });
}

By running flutter test test/unit/user_repository_test.dart, you can verify your business logic in milliseconds. This rapid feedback loop is why unit tests should make up the bulk of your test suite.

With widget testing flutter bridges the gap between ultra-fast unit tests and high-fidelity integration tests. Widget tests allow you to render a single widget—or a tree of widgets—in a simulated, headless environment. This means you can test complex UI layouts, animations, and user interactions (like taps, scrolls, and text input) in a fraction of a second, completely bypassing the need to boot up an iOS Simulator or Android Emulator.

This section of our testing flutter apps guide will demonstrate how to test a stateful interactive widget: a custom subscription toggle card.

// lib/widgets/subscription_card.dart
import 'package:flutter/material.dart';
 
class SubscriptionCard extends StatefulWidget {
  final String planName;
  final double price;
  final ValueChanged<bool> onSelectionChanged;
 
  const SubscriptionCard({
    super.key,
    required this.planName,
    required this.price,
    required this.onSelectionChanged,
  });
 
  @override
  State<SubscriptionCard> createState() => _SubscriptionCardState();
}
 
class _SubscriptionCardState extends State<SubscriptionCard> {
  bool _isSelected = false;
 
  @override
  Widget build(BuildContext context) {
    return AnimatedContainer(
      duration: const Duration(milliseconds: 200),
      padding: const EdgeInsets.all(16.0),
      decoration: BoxDecoration(
        color: _isSelected ? Colors.blue.withOpacity(0.1) : Colors.white,
        border: Border.all(
          color: _isSelected ? Colors.blue : Colors.grey.shade300,
          width: 2.0,
        ),
        borderRadius: BorderRadius.circular(12.0),
      ),
      child: Row(
        mainAxisAlignment: MainAxisAlignment.between,
        children: [
          Column(
            crossAxisAlignment: CrossAxisAlignment.start,
            children: [
              Text(
                widget.planName,
                style: const TextStyle(fontSize: 18, fontWeight: FontWeight.bold),
              ),
              const SizedBox(height: 4),
              Text('\$${widget.price.toStringAsFixed(2)}/month'),
            ],
          ),
          Switch(
            key: const Key('subscription_switch'),
            value: _isSelected,
            onChanged: (value) {
              setState(() {
                _isSelected = value;
              });
              widget.onSelectionChanged(value);
            },
          ),
        ],
      ),
    );
  }
}

To test this widget, we use the flutter_test package. We will verify that the widget renders the correct text, responds to user interaction (toggling the switch), and triggers the callback function.

// test/widgets/subscription_card_test.dart
import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:my_app/widgets/subscription_card.dart';
 
void main() {
  group('SubscriptionCard Widget Tests', () {
    testWidgets('should render plan details correctly', (WidgetTester tester) async {
      // Render the widget inside a MaterialApp to provide localization and theme context
      await tester.pumpWidget(
        MaterialApp(
          home: Scaffold(
            body: SubscriptionCard(
              planName: 'Premium Pro',
              price: 29.99,
              onSelectionChanged: (_) {},
            ),
          ),
        ),
      );
 
      // Finders: Locate elements in the widget tree
      final planNameFinder = find.text('Premium Pro');
      final priceFinder = find.text('\$29.99/month');
      final switchFinder = find.byKey(const Key('subscription_switch'));
 
      // Assertions: Verify elements exist and are visible
      expect(planNameFinder, findsOneWidget);
      expect(priceFinder, findsOneWidget);
      expect(switchFinder, findsOneWidget);
 
      // Verify the initial state of the switch is false (inactive)
      final Switch subscriptionSwitch = tester.widget<Switch>(switchFinder);
      expect(subscriptionSwitch.value, isFalse);
    });
 
    testWidgets('should toggle state and trigger callback when tapped', (WidgetTester tester) async {
      bool? callbackValue;
 
      await tester.pumpWidget(
        MaterialApp(
          home: Scaffold(
            body: SubscriptionCard(
              planName: 'Premium Pro',
              price: 29.99,
              onSelectionChanged: (val) {
                callbackValue = val;
              },
            ),
          ),
        ),
      );
 
      final switchFinder = find.byKey(const Key('subscription_switch'));
 
      // Act: Simulate a user tap on the switch
      await tester.tap(switchFinder);
 
      // Rebuild the widget tree to reflect the state change (trigger animations/setState)
      await tester.pumpAndSettle();
 
      // Assert: Verify the switch state updated
      final Switch updatedSwitch = tester.widget<Switch>(switchFinder);
      expect(updatedSwitch.value, isTrue);
 
      // Assert: Verify the callback was executed with the correct value
      expect(callbackValue, isTrue);
    });
  });
}

While unit and widget tests verify isolated parts of your codebase, they cannot guarantee that your entire application works seamlessly together. To run an integration test mobile app flows require, you must execute the code in a real runtime environment. This ensures that your routing, state management, local storage, and network layers operate in harmony.

Flutter provides the native integration_test package, which runs tests directly on physical devices or emulators by compiling your test code alongside your application.

Step 1: Add Dependencies

Add the integration_test dependency to your pubspec.yaml:

dev_dependencies:
  flutter_test:
    sdk: flutter
  integration_test:
    sdk: flutter

Step 2: Create the Integration Test File

Integration tests reside in a dedicated directory named integration_test/ at the root of your project. Let's write an end-to-end test that simulates a user logging in and navigating to the settings screen.

// integration_test/app_flow_test.dart
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() {
  // Ensure the integration test driver is initialized
  IntegrationTestWidgetsFlutterBinding.ensureInitialized();
 
  group('End-to-End App Flow Test', () {
    testWidgets('Verify login and navigation to settings', (WidgetTester tester) async {
      // Start the app
      app.main();
      await tester.pumpAndSettle();
 
      // 1. Locate login form fields
      final emailField = find.byKey(const Key('email_input_field'));
      final passwordField = find.byKey(const Key('password_input_field'));
      final loginButton = find.byKey(const Key('login_submit_button'));
 
      // Verify we are on the login screen
      expect(find.text('Welcome Back'), findsOneWidget);
 
      // 2. Enter credentials
      await tester.enterText(emailField, 'qa@vyrova.tech');
      await tester.enterText(passwordField, 'SecurePassword123!');
      await tester.pumpAndSettle();
 
      // 3. Tap login button
      await tester.tap(loginButton);
      
      // Wait for network request and transition animation to complete
      await tester.pumpAndSettle(const Duration(seconds: 2));
 
      // 4. Verify successful navigation to Dashboard
      expect(find.text('User Dashboard'), findsOneWidget);
 
      // 5. Navigate to Settings
      final settingsTab = find.byIcon(Icons.settings);
      await tester.tap(settingsTab);
      await tester.pumpAndSettle();
 
      // 6. Verify Settings Screen elements
      expect(find.text('Account Settings'), findsOneWidget);
      expect(find.text('Logout'), findsOneWidget);
    });
  });
}

Step 3: Running the Integration Test

To run this test on a connected physical device or running emulator, execute the following command in your terminal:

flutter test integration_test/app_flow_test.dart

For running tests on web or specific desktop platforms, you can specify the target device:

flutter drive \
  --driver=test_driver/integration_test.dart \
  --target=integration_test/app_flow_test.dart \
  -d chrome

Code Coverage Metrics: Setting Up Quality Gates

A key aspect of any professional testing flutter apps guide is establishing code coverage metrics. Code coverage measures the percentage of your codebase executed during test runs. While 100% coverage is rarely a practical goal, maintaining a consistent coverage threshold (e.g., 80%) ensures that new features are not shipped without accompanying tests.

Generating Coverage Reports

Flutter has built-in support for generating LCOV coverage files. Run your tests with the --coverage flag:

flutter test --coverage

This command generates a coverage/lcov.info file containing detailed line-by-line coverage data.

Filtering Out Generated Files

Modern Flutter projects often rely heavily on code generation (e.g., Freezed, JSON Serializable, Riverpod generators). Including these generated files in your coverage metrics artificially skews your results. You can filter them out using the remove_from_coverage package or a simple shell script.

Here is a bash script to clean up your coverage data before analysis:

#!/bin/bash
 
# Run tests and generate lcov.info
flutter test --coverage
 
# Check if lcov is installed
if command -v lcov &> /dev/null
then
    # Remove generated files and localization files from coverage report
    lcov --remove coverage/lcov.info \
      'lib/**/*.g.dart' \
      'lib/**/*.freezed.dart' \
      'lib/generated/*' \
      -o coverage/clean_lcov.info
else
    echo "lcov is not installed. Install it via 'brew install lcov' to filter reports."
fi

Visualizing Coverage Locally

To convert the raw lcov.info file into a readable HTML report, use the genhtml tool (part of the lcov suite):

genhtml coverage/clean_lcov.info -o coverage/html
open coverage/html/index.html

This opens an interactive browser window showing exactly which lines of code are covered (green) and which are missed (red).

Section               Line Coverage       Branches
--------------------------------------------------------
lib/repositories/     92.4 % (122/132)    80.0 % (8/10)
lib/services/         85.7 % (60/70)      75.0 % (6/8)
lib/widgets/          78.1 % (250/320)    60.0 % (12/20)

Looking for Premium Mobile App Developers?

We build high-performance, native-grade cross-platform apps using Flutter and React Native. Let's discuss your product goals.

Get a Mobile Dev Quote

Running Tests Automatically inside CI/CD Pipelines

To truly enforce quality gates, your test suite must run automatically on every pull request and branch merge. This prevents broken code from ever reaching your production branches.

Below is a production-ready GitHub Actions workflow configuration (.github/workflows/flutter_ci.yml) that automates dependency installation, static analysis, unit/widget testing, and coverage verification.

name: Flutter CI/CD Pipeline
 
on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main, develop ]
 
jobs:
  analyze_and_test:
    runs-on: ubuntu-latest
 
    steps:
      # 1. Checkout the repository
      - name: Checkout Code
        uses: actions/checkout@v4
 
      # 2. Set up Java (required for Android builds/testing)
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          distribution: 'zulu'
          java-version: '17'
 
      # 3. Set up Flutter SDK
      - name: Set up Flutter
        uses: subosito/flutter-action@v2
        with:
          flutter-version: '3.19.x'
          channel: 'stable'
          cache: true
          cache-key: "flutter-:os:-:channel:-:version:-:arch:-:hash:"
 
      # 4. Install dependencies
      - name: Install Dependencies
        run: flutter pub get
 
      # 5. Run static analysis (Linter)
      - name: Analyze Code
        run: flutter analyze
 
      # 6. Check formatting
      - name: Check Formatting
        run: flutter format --set-exit-if-changed lib/
 
      # 7. Run Unit and Widget Tests with Coverage
      - name: Run Tests
        run: flutter test --coverage
 
      # 8. Enforce Coverage Threshold (Quality Gate)
      - name: Verify Minimum Coverage
        uses: VeryGoodOpenSource/very_good_coverage@v2
        with:
          path: ./coverage/lcov.info
          min_coverage: 80 # Fails the build if coverage drops below 80%
 
      # 9. Upload Coverage Reports to Codecov (Optional)
      - name: Upload Coverage to Codecov
        uses: codecov/codecov-action@v3
        with:
          token: ${{ secrets.CODECOV_TOKEN }}
          files: ./coverage/lcov.info
          fail_ci_if_error: true

Continuous Integration Best Practices

Caching: Always enable caching for your Flutter SDK and pub packages (as shown in step 3). This can reduce your CI build times by up to 60%.
Strict Linting: Treat linter warnings as errors. Run flutter analyze to catch potential runtime bugs, unused imports, and styling inconsistencies before running tests.
Parallelization: If your test suite grows exceptionally large, split your unit/widget tests and integration tests into separate parallel jobs to keep your feedback loop fast.
Device Farms: For integration testing, run tests on real device clouds like Firebase Test Lab, AWS Device Farm, or Kobiton directly from your CI pipeline to ensure compatibility across diverse hardware and OS versions.

By implementing the strategies outlined in this guide, your engineering team will possess the tools and patterns required to build highly reliable, maintainable, and scalable Flutter applications. Happy testing!

Quality Assurance: Mastering the Testing Pyramid in Flutter

       /\
      /  \      Integration Tests (High Fidelity, Slow, Real Devices)
     /----\
    /      \    Widget Tests (Medium Fidelity, Fast, Headless UI)
   /--------\
  /          \  Unit Tests (Low Fidelity, Ultra-Fast, Business Logic)
 /____________\

The testing pyramid is a conceptual framework that guides how you should distribute your testing efforts:

Unit Tests: Focus on isolated blocks of code—such as functions, methods, and state managers—without external dependencies. They are extremely fast and cheap to run.
Widget Tests: Also known as component tests in other ecosystems. They isolate individual UI components or screens, rendering them in a headless test environment to verify layout, rendering, and user interactions without the overhead of an emulator.
Integration Tests: Run the entire application on a real device or emulator, testing end-to-end user journeys, network communication, and native platform integrations.

By balancing these three layers, you can build a highly resilient test suite that catches bugs early in the development lifecycle, minimizes manual QA overhead, and accelerates your release velocity.

Unit Testing Dart Code: Mocking Dependencies with Mockito/Mocktail

Let's look at a real-world scenario: testing a UserRepository that depends on an ApiClient to fetch user profiles.

Step 1: Define the Domain Model and Service Interface

First, we define our data model and the API client interface.

// lib/models/user.dart
class User {
  final String id;
  final String name;
  final String email;
 
  User({required this.id, required this.name, required this.email});
 
  factory User.fromJson(Map<String, dynamic> json) {
    return User(
      id: json['id'] as String,
      name: json['name'] as String,
      email: json['email'] as String,
    );
  }
}
 
// lib/services/api_client.dart
import 'package:http/http.dart' as http;
 
class ApiClient {
  final http.Client httpClient;
  final String baseUrl;
 
  ApiClient({required this.httpClient, required this.baseUrl});
 
  Future<Map<String, dynamic>> get(String path) async {
    final response = await httpClient.get(Uri.parse('$baseUrl$path'));
    if (response.statusCode == 200) {
      return Map<String, dynamic>.from(
        Uri.decodeComponent(response.body) as Map,
      );
    } else {
      throw Exception('Network Error: ${response.statusCode}');
    }
  }
}

Step 2: Implement the Repository with Dependency Injection

We inject the ApiClient into our repository. This design pattern is crucial for testability.

// lib/repositories/user_repository.dart
import 'package:my_app/models/user.dart';
import 'package:my_app/services/api_client.dart';
 
class UserRepository {
  final ApiClient apiClient;
 
  UserRepository({required this.apiClient});
 
  Future<User> getUserProfile(String userId) async {
    try {
      final data = await apiClient.get('/users/$userId');
      return User.fromJson(data);
    } catch (e) {
      throw Exception('Failed to fetch user profile: $e');
    }
  }
}

Step 3: Write the Unit Test with Mocktail

Now, we write our unit tests. We will mock the ApiClient to simulate both successful API responses and network failures.

// test/unit/user_repository_test.dart
import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';
import 'package:my_app/models/user.dart';
import 'package:my_app/services/api_client.dart';
import 'package:my_app/repositories/user_repository.dart';
 
// Create a mock class by extending Mock and implementing the target class
class MockApiClient extends Mock implements ApiClient {}
 
void main() {
  late MockApiClient mockApiClient;
  late UserRepository userRepository;
 
  setUp(() {
    mockApiClient = MockApiClient();
    userRepository = UserRepository(apiClient: mockApiClient);
  });
 
  group('UserRepository - getUserProfile', () {
    const userId = 'usr_12345';
    const mockUserJson = {
      'id': 'usr_12345',
      'name': 'Jane Doe',
      'email': 'jane.doe@vyrova.tech',
    };
 
    test('should return a User model when the API call is successful', () async {
      // Arrange: Stub the mock API client to return a successful response
      when(() => mockApiClient.get('/users/$userId'))
          .thenAnswer((_) async => mockUserJson);
 
      // Act: Call the repository method
      final result = await userRepository.getUserProfile(userId);
 
      // Assert: Verify the results and interactions
      expect(result, isA<User>());
      expect(result.id, equals('usr_12345'));
      expect(result.name, equals('Jane Doe'));
      expect(result.email, equals('jane.doe@vyrova.tech'));
      
      // Verify that the API client was called exactly once with the correct path
      verify(() => mockApiClient.get('/users/$userId')).called(1);
    });
 
    test('should throw an exception when the API call fails', () async {
      // Arrange: Stub the mock API client to throw an exception
      when(() => mockApiClient.get('/users/$userId'))
          .thenThrow(Exception('Internal Server Error'));
 
      // Act & Assert: Verify that the repository propagates the exception
      expect(
        () => userRepository.getUserProfile(userId),
        throwsA(isA<Exception>()),
      );
 
      verify(() => mockApiClient.get('/users/$userId')).called(1);
    });
  });
}

This section of our testing flutter apps guide will demonstrate how to test a stateful interactive widget: a custom subscription toggle card.

// lib/widgets/subscription_card.dart
import 'package:flutter/material.dart';
 
class SubscriptionCard extends StatefulWidget {
  final String planName;
  final double price;
  final ValueChanged<bool> onSelectionChanged;
 
  const SubscriptionCard({
    super.key,
    required this.planName,
    required this.price,
    required this.onSelectionChanged,
  });
 
  @override
  State<SubscriptionCard> createState() => _SubscriptionCardState();
}
 
class _SubscriptionCardState extends State<SubscriptionCard> {
  bool _isSelected = false;
 
  @override
  Widget build(BuildContext context) {
    return AnimatedContainer(
      duration: const Duration(milliseconds: 200),
      padding: const EdgeInsets.all(16.0),
      decoration: BoxDecoration(
        color: _isSelected ? Colors.blue.withOpacity(0.1) : Colors.white,
        border: Border.all(
          color: _isSelected ? Colors.blue : Colors.grey.shade300,
          width: 2.0,
        ),
        borderRadius: BorderRadius.circular(12.0),
      ),
      child: Row(
        mainAxisAlignment: MainAxisAlignment.between,
        children: [
          Column(
            crossAxisAlignment: CrossAxisAlignment.start,
            children: [
              Text(
                widget.planName,
                style: const TextStyle(fontSize: 18, fontWeight: FontWeight.bold),
              ),
              const SizedBox(height: 4),
              Text('\$${widget.price.toStringAsFixed(2)}/month'),
            ],
          ),
          Switch(
            key: const Key('subscription_switch'),
            value: _isSelected,
            onChanged: (value) {
              setState(() {
                _isSelected = value;
              });
              widget.onSelectionChanged(value);
            },
          ),
        ],
      ),
    );
  }
}

// test/widgets/subscription_card_test.dart
import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:my_app/widgets/subscription_card.dart';
 
void main() {
  group('SubscriptionCard Widget Tests', () {
    testWidgets('should render plan details correctly', (WidgetTester tester) async {
      // Render the widget inside a MaterialApp to provide localization and theme context
      await tester.pumpWidget(
        MaterialApp(
          home: Scaffold(
            body: SubscriptionCard(
              planName: 'Premium Pro',
              price: 29.99,
              onSelectionChanged: (_) {},
            ),
          ),
        ),
      );
 
      // Finders: Locate elements in the widget tree
      final planNameFinder = find.text('Premium Pro');
      final priceFinder = find.text('\$29.99/month');
      final switchFinder = find.byKey(const Key('subscription_switch'));
 
      // Assertions: Verify elements exist and are visible
      expect(planNameFinder, findsOneWidget);
      expect(priceFinder, findsOneWidget);
      expect(switchFinder, findsOneWidget);
 
      // Verify the initial state of the switch is false (inactive)
      final Switch subscriptionSwitch = tester.widget<Switch>(switchFinder);
      expect(subscriptionSwitch.value, isFalse);
    });
 
    testWidgets('should toggle state and trigger callback when tapped', (WidgetTester tester) async {
      bool? callbackValue;
 
      await tester.pumpWidget(
        MaterialApp(
          home: Scaffold(
            body: SubscriptionCard(
              planName: 'Premium Pro',
              price: 29.99,
              onSelectionChanged: (val) {
                callbackValue = val;
              },
            ),
          ),
        ),
      );
 
      final switchFinder = find.byKey(const Key('subscription_switch'));
 
      // Act: Simulate a user tap on the switch
      await tester.tap(switchFinder);
 
      // Rebuild the widget tree to reflect the state change (trigger animations/setState)
      await tester.pumpAndSettle();
 
      // Assert: Verify the switch state updated
      final Switch updatedSwitch = tester.widget<Switch>(switchFinder);
      expect(updatedSwitch.value, isTrue);
 
      // Assert: Verify the callback was executed with the correct value
      expect(callbackValue, isTrue);
    });
  });
}

Flutter provides the native integration_test package, which runs tests directly on physical devices or emulators by compiling your test code alongside your application.

Step 1: Add Dependencies

Add the integration_test dependency to your pubspec.yaml:

dev_dependencies:
  flutter_test:
    sdk: flutter
  integration_test:
    sdk: flutter

Step 2: Create the Integration Test File

// integration_test/app_flow_test.dart
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() {
  // Ensure the integration test driver is initialized
  IntegrationTestWidgetsFlutterBinding.ensureInitialized();
 
  group('End-to-End App Flow Test', () {
    testWidgets('Verify login and navigation to settings', (WidgetTester tester) async {
      // Start the app
      app.main();
      await tester.pumpAndSettle();
 
      // 1. Locate login form fields
      final emailField = find.byKey(const Key('email_input_field'));
      final passwordField = find.byKey(const Key('password_input_field'));
      final loginButton = find.byKey(const Key('login_submit_button'));
 
      // Verify we are on the login screen
      expect(find.text('Welcome Back'), findsOneWidget);
 
      // 2. Enter credentials
      await tester.enterText(emailField, 'qa@vyrova.tech');
      await tester.enterText(passwordField, 'SecurePassword123!');
      await tester.pumpAndSettle();
 
      // 3. Tap login button
      await tester.tap(loginButton);
      
      // Wait for network request and transition animation to complete
      await tester.pumpAndSettle(const Duration(seconds: 2));
 
      // 4. Verify successful navigation to Dashboard
      expect(find.text('User Dashboard'), findsOneWidget);
 
      // 5. Navigate to Settings
      final settingsTab = find.byIcon(Icons.settings);
      await tester.tap(settingsTab);
      await tester.pumpAndSettle();
 
      // 6. Verify Settings Screen elements
      expect(find.text('Account Settings'), findsOneWidget);
      expect(find.text('Logout'), findsOneWidget);
    });
  });
}

Step 3: Running the Integration Test

To run this test on a connected physical device or running emulator, execute the following command in your terminal:

flutter test integration_test/app_flow_test.dart

For running tests on web or specific desktop platforms, you can specify the target device:

flutter drive \
  --driver=test_driver/integration_test.dart \
  --target=integration_test/app_flow_test.dart \
  -d chrome

Code Coverage Metrics: Setting Up Quality Gates

Generating Coverage Reports

Flutter has built-in support for generating LCOV coverage files. Run your tests with the --coverage flag:

flutter test --coverage

This command generates a coverage/lcov.info file containing detailed line-by-line coverage data.

Filtering Out Generated Files

Here is a bash script to clean up your coverage data before analysis:

#!/bin/bash
 
# Run tests and generate lcov.info
flutter test --coverage
 
# Check if lcov is installed
if command -v lcov &> /dev/null
then
    # Remove generated files and localization files from coverage report
    lcov --remove coverage/lcov.info \
      'lib/**/*.g.dart' \
      'lib/**/*.freezed.dart' \
      'lib/generated/*' \
      -o coverage/clean_lcov.info
else
    echo "lcov is not installed. Install it via 'brew install lcov' to filter reports."
fi

Visualizing Coverage Locally

To convert the raw lcov.info file into a readable HTML report, use the genhtml tool (part of the lcov suite):

genhtml coverage/clean_lcov.info -o coverage/html
open coverage/html/index.html

This opens an interactive browser window showing exactly which lines of code are covered (green) and which are missed (red).

Section               Line Coverage       Branches
--------------------------------------------------------
lib/repositories/     92.4 % (122/132)    80.0 % (8/10)
lib/services/         85.7 % (60/70)      75.0 % (6/8)
lib/widgets/          78.1 % (250/320)    60.0 % (12/20)

Looking for Premium Mobile App Developers?

We build high-performance, native-grade cross-platform apps using Flutter and React Native. Let's discuss your product goals.

Get a Mobile Dev Quote

Running Tests Automatically inside CI/CD Pipelines

To truly enforce quality gates, your test suite must run automatically on every pull request and branch merge. This prevents broken code from ever reaching your production branches.

name: Flutter CI/CD Pipeline
 
on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main, develop ]
 
jobs:
  analyze_and_test:
    runs-on: ubuntu-latest
 
    steps:
      # 1. Checkout the repository
      - name: Checkout Code
        uses: actions/checkout@v4
 
      # 2. Set up Java (required for Android builds/testing)
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          distribution: 'zulu'
          java-version: '17'
 
      # 3. Set up Flutter SDK
      - name: Set up Flutter
        uses: subosito/flutter-action@v2
        with:
          flutter-version: '3.19.x'
          channel: 'stable'
          cache: true
          cache-key: "flutter-:os:-:channel:-:version:-:arch:-:hash:"
 
      # 4. Install dependencies
      - name: Install Dependencies
        run: flutter pub get
 
      # 5. Run static analysis (Linter)
      - name: Analyze Code
        run: flutter analyze
 
      # 6. Check formatting
      - name: Check Formatting
        run: flutter format --set-exit-if-changed lib/
 
      # 7. Run Unit and Widget Tests with Coverage
      - name: Run Tests
        run: flutter test --coverage
 
      # 8. Enforce Coverage Threshold (Quality Gate)
      - name: Verify Minimum Coverage
        uses: VeryGoodOpenSource/very_good_coverage@v2
        with:
          path: ./coverage/lcov.info
          min_coverage: 80 # Fails the build if coverage drops below 80%
 
      # 9. Upload Coverage Reports to Codecov (Optional)
      - name: Upload Coverage to Codecov
        uses: codecov/codecov-action@v3
        with:
          token: ${{ secrets.CODECOV_TOKEN }}
          files: ./coverage/lcov.info
          fail_ci_if_error: true

Continuous Integration Best Practices

Caching: Always enable caching for your Flutter SDK and pub packages (as shown in step 3). This can reduce your CI build times by up to 60%.
Strict Linting: Treat linter warnings as errors. Run flutter analyze to catch potential runtime bugs, unused imports, and styling inconsistencies before running tests.
Parallelization: If your test suite grows exceptionally large, split your unit/widget tests and integration tests into separate parallel jobs to keep your feedback loop fast.
Device Farms: For integration testing, run tests on real device clouds like Firebase Test Lab, AWS Device Farm, or Kobiton directly from your CI pipeline to ensure compatibility across diverse hardware and OS versions.

Quality Assurance: Mastering the Testing Pyramid in Flutter

Unit Testing Dart Code: Mocking Dependencies with Mockito/Mocktail

Step 1: Define the Domain Model and Service Interface

Step 2: Implement the Repository with Dependency Injection

Step 3: Write the Unit Test with Mocktail

Widget Testing: Simulating UX Interactions Without Emulator Overheads

The Widget Under Test

Writing the Widget Test

Key Widget Testing Concepts

Integration Testing: Automated App Navigation on Actual Devices

Step 1: Add Dependencies

Step 2: Create the Integration Test File

Step 3: Running the Integration Test

Code Coverage Metrics: Setting Up Quality Gates

Generating Coverage Reports

Filtering Out Generated Files

Visualizing Coverage Locally

Looking for Premium Mobile App Developers?

Running Tests Automatically inside CI/CD Pipelines

Continuous Integration Best Practices

Related Articles

Setting Up CI/CD for Flutter Apps With Codemagic

Deploying Flutter Apps to Apple App Store and Google Play

Flutter Performance Optimization: How to Build Lag-Free Apps

Quality Assurance: Mastering the Testing Pyramid in Flutter

Unit Testing Dart Code: Mocking Dependencies with Mockito/Mocktail

Step 1: Define the Domain Model and Service Interface

Step 2: Implement the Repository with Dependency Injection

Step 3: Write the Unit Test with Mocktail

Widget Testing: Simulating UX Interactions Without Emulator Overheads

The Widget Under Test

Writing the Widget Test

Key Widget Testing Concepts

Integration Testing: Automated App Navigation on Actual Devices

Step 1: Add Dependencies

Step 2: Create the Integration Test File

Step 3: Running the Integration Test

Code Coverage Metrics: Setting Up Quality Gates

Generating Coverage Reports

Filtering Out Generated Files

Visualizing Coverage Locally

Looking for Premium Mobile App Developers?

Running Tests Automatically inside CI/CD Pipelines

Continuous Integration Best Practices

Related Articles

Setting Up CI/CD for Flutter Apps With Codemagic

Deploying Flutter Apps to Apple App Store and Google Play

Flutter Performance Optimization: How to Build Lag-Free Apps