Testing Overview

At Very Good Ventures, our goal is to achieve 100% test coverage on all projects. Writing tests not only helps to reduce the number of bugs, but also encourages code to be written in a very clean, consistent, and maintainable way. While testing can initially add some additional time to the project, the trade-off is fewer bugs, higher confidence when shipping, and less time spent in QA cycles.

Organize test files

Test files should be organized to match your project file structure.

This my_package library contains models and widgets. The test folder should copy this structure:

• Directorymy_package/

  • Directorylib/

    • Directorymodels/

      • model_a.dart
      • model_b.dart
      • models.dart
    • Directorywidgets/

      • widget_1.dart
      • widget_2.dart
      • widgets.dart
  • test/ …

Good ✅

• Directorytest/

  • Directorymodels/

    • model_a_test.dart
    • model_b_test.dart
  • Directorywidgets/

    • widget_1_test.dart
    • widget_2_test.dart

Bad ❗️

• Directorytest/

  • model_a_test.dart
  • model_b_test.dart
  • widgets_test.dart

Note: models.dart and widgets.dart are barrel files and do not need to be tested.

Tip

You can automatically create or find a test file when using the Flutter VS Code Extension by right-clicking on the file within the explorer view and selecting “Go to Tests” or using the “Go to Test/Implementation File” command within the command palette.

Note

You can find more information about package layouts in the Dart Package layout conventions and in What makes a package.

Assert test results using expect or verify

All tests should have one or more statements at the end of the test asserting the test result using either an expect or verify.

Good ✅

testWidgets('calls [onTap] on tapping widget', (tester) async {
  var isTapped = false;
  await tester.pumpWidget(
    SomeTappableWidget(
      onTap: () => isTapped = true,
    ),
  );
  await tester.pumpAndSettle();

  await tester.tap(SomeTappableWidget());
  await tester.pumpAndSettle();

  expect(isTapped, isTrue);
});

Bad ❗️

testWidgets('can tap widget', (tester) async {
  await tester.pumpWidget(SomeTappableWidget());
  await tester.pumpAndSettle();

  await tester.tap(SomeTappableWidget());
  await tester.pumpAndSettle();
});

The above test would pass coverage on SomeTappableWidget, and pass as long as no exception is thrown, but it doesn’t really tell any valuable information about what the widget should do.

Now, we are explicitly testing that we have accessed the onTap property of SomeTappableWidget, which makes this test more valuable, because its behavior is also tested.

Use matchers and expectations

Matchers provides better messages in tests and should always be used in expectations.

Good ✅

expect(name, equals('Hank'));
expect(people, hasLength(3));
expect(valid, isTrue);

Bad ❗️

expect(name, 'Hank');
expect(people.length, 3);
expect(valid, true);

Test with a single purpose

Aim to test one scenario per test. You might end up with more tests in the codebase, but this is preferred over creating one single test to cover several cases. This helps with readability and debugging failing tests.

Good ✅

testWidgets('renders $WidgetA', (tester) async {});
testWidgets('renders $WidgetB', (tester) async {});

Bad ❗️

testWidgets('renders $WidgetA and $WidgetB', (tester) async {});

Test behavior, not properties

When testing, especially when testing widgets, we should test the behavior of the widget, not its properties. For example, write a test that verifies tapping a button triggers the correct action, but don’t waste time verifying the button has the correct padding if it’s a static number in the code.

Good ✅

testWidgets('navigates to settings when button is tapped', (tester) async {
  await tester.pumpWidget(MyApp());

  await tester.tap(find.byType(SettingsButton));
  await tester.pumpAndSettle();

  expect(find.byType(SettingsPage), findsOneWidget);
});

testWidgets('displays error message when login fails', (tester) async {
  await tester.pumpWidget(LoginPage());

  await tester.enterText(find.byType(TextField), 'invalid@email.com');
  await tester.tap(find.byType(LoginButton));
  await tester.pumpAndSettle();

  expect(find.text('Invalid credentials'), findsOneWidget);
});

Bad ❗️

testWidgets('button has correct padding', (tester) async {
  await tester.pumpWidget(
    SettingsButton(
      padding: EdgeInsets.all(16),
    ),
  );

  final button = tester.widget<SettingsButton>(find.byType(SettingsButton));
  expect(button.padding, equals(EdgeInsets.all(16)));
});

testWidgets('text color is red', (tester) async {
  await tester.pumpWidget(ErrorText('Error'));

  final text = tester.widget<Text>(find.text('Error'));
  expect(text.style?.color, equals(Colors.red));
});

Of course, if the color of a widget changes based on state, that should be tested since you’re testing the behavior of the widget. However, if it’s a static color, it’s better tested by golden tests or visual QA.

Split your tests by groups

Having multiple tests in a class could cause problems with readability. It is better to split your tests into groups:

• Widget tests: you could potentially group by “renders”, “navigation”, etc.
• Bloc tests: group by the name of the event.
• Repositories and clients: group by name of the method you are testing.

Tip: If your test file starts to become unreadable or unmanageable, consider splitting the file that you are testing into smaller files.