How do you plan a Flutter test strategy?

A useful test pyramid in Flutter is broad at the unit level, focused at the widget level and narrow at the integration level. Unit tests are fast and catch business rule errors. Widget tests catch rendering and interaction issues without a device. Integration tests prove the app works with real plugins and navigation, but they are slow and flaky if overused.

test('applies discount above threshold', () {
  final cart = Cart(items: [Item(price: 1200), Item(price: 300)]);

  expect(cart.subtotal, 1500);
  expect(cart.discount, 150);
  expect(cart.total, 1350);
});

• Test pure logic, serialization, validators and state transitions as units
• Use widget tests for layout states, taps, text entry and semantics
• Use integration tests for login, checkout and deep-link journeys
• Fake repositories at the boundary rather than mocking every internal call
• Run tests in CI on every pull request and track coverage trends, not a single number

What makes tests valuable

A test should fail for a meaningful reason and describe behaviour, not implementation. Over-mocking makes tests pass while production breaks. Include error, loading and empty states, not only the happy path. Golden tests are useful for visual regressions but need a controlled font and rendering environment.