Testing

Overview

Testing is a crucial part of building robust and maintainable applications. The Flutter Kit is designed with testability in mind. This guide outlines our recommended approach, distinguishing between Unit and Widget tests based on a simple framework:

• Unit Tests: input <-> output
• Widget Tests: action <-> result

Unit Testing (input <-> output)

Unit tests are best suited for testing isolated pieces of logic, particularly pure functions or methods with predictable inputs and outputs. They should be fast, self-contained, and have minimal dependencies. The goal is to verify that given a specific input, the function reliably produces the expected output.

When to Use:

• Utility or helper functions.
• Specific data transformation/validation logic that can be easily isolated.

Example:

Consider a simple utility function:

1
bool isEmailValid(String email) {
2
  if (email.isEmpty) return false;
3
  // Basic check for demonstration
4
  return email.contains('@') && email.contains('.');
5
}

A unit test verifies its input/output behavior:

1
void main() {
2
  test('isEmailValid should return true for valid emails', () {
3
    expect(isEmailValid('test@example.com'), isTrue);
4
  });
5

6
  test('isEmailValid should return false for invalid emails', () {
7
    expect(isEmailValid('testexample.com'), isFalse);
8
    expect(isEmailValid('test@examplecom'), isFalse);
9
    expect(isEmailValid(''), isFalse);
10
  });
11
}

Complex classes with multiple dependencies (like full ViewModels or Services interacting with external systems) are generally better tested through Widget tests in this architecture, as isolating them for pure unit tests often requires excessive mocking.

For more context on the input <-> output approach, refer to the Widget vs Unit Testing article.

Widget Testing (action <-> result)

Widget tests are the primary way to test the functionality of your features. In the MVVM pattern used by the boilerplate, a View and its ViewModel are tightly coupled (1-to-1) and should be tested together as a single unit. The focus is on verifying that user actions lead to the expected results in the UI and state.

When to Use:

• Testing the behavior of a complete screen or component.
• Verifying UI rendering based on ViewModel state.
• Ensuring interactions (button taps, form submissions) trigger the correct logic in the ViewModel and update the UI accordingly.

Example:

Imagine a simple counter view/viewmodel:

1
class CounterViewModel {
2
  final ValueNotifier<int> counter = ValueNotifier(0);
3

4
  void incrementCounter() {
5
    counter.value++;
6
  }
7

8
  void dispose() {
9
    counter.dispose();
10
  }
11
}

1
class CounterView extends StatefulWidget {
2
  const CounterView({super.key});
3

4
  @override
5
  State<CounterView> createState() => _CounterViewState();
6
}
7

8
class _CounterViewState extends State<CounterView> {
9
  late final CounterViewModel _viewModel;
10

11
  @override
12
  void initState() {
13
    super.initState();
14
    _viewModel = CounterViewModel();
15
  }
16

17
  @override
18
  void dispose() {
19
    _viewModel.dispose();
20
    super.dispose();
21
  }
22

23
  @override
24
  Widget build(BuildContext context) {
25
    return Scaffold(
26
      body: Column(
27
        mainAxisAlignment: MainAxisAlignment.center,
28
        children: [
29
          ValueListenableBuilder<int>(
30
            valueListenable: _viewModel.counter,
31
            builder: (context, value, _) {
32
              return Text('Counter: $value');
33
            },
34
          ),
35
          ElevatedButton(
36
            onPressed: _viewModel.incrementCounter,
37
            child: const Text('Increment'),
38
          ),
39
        ],
40
      ),
41
    );
42
  }
43
}

A widget test verifies the action-result flow:

1
void main() {
2
  testWidgets('CounterView increments counter when button is pressed', (WidgetTester tester) async {
3
    // Arrange: Pump the widget
4
    await tester.pumpWidget(MaterialApp(home: CounterView()));
5

6
    // Assert: Initial state (result)
7
    expect(find.text('Counter: 0'), findsOneWidget);
8

9
    // Act: Simulate user action (tap the button)
10
    await tester.tap(find.byType(ElevatedButton));
11
    await tester.pump(); // Rebuild the widget tree
12

13
    // Assert: Final state (result after action)
14
    expect(find.text('Counter: 1'), findsOneWidget);
15
  });
16
}

Notice how we test the CounterView directly. The test verifies that the action (tapping the button) correctly interacts with the ViewModel logic (instantiated within the View’s state) and produces the expected result (the text updates to ‘Counter: 1’). This single test covers both the View’s rendering and the ViewModel’s core logic for this feature.

For more details on the action <-> result approach and further examples, refer to the Widget vs Unit Testing article.