Test Automation
Flutter's widget testing layer sits between unit tests and full integration tests. It gives you a real widget tree rendered in a test environment — fast, hermetic, and powerful enough to catch real bugs. But most tutorials stop at pumpWidget and find.text. This post goes further, covering the
Flutter
TDD in Flutter means writing a failing test first, then writing just enough code to make it pass, then refactoring. The same red-green-refactor loop works for pure Dart unit tests, Flutter widget tests, and state management layers. This tutorial walks through building a real feature with TDD from
Flutter
Testing Riverpod providers means working with ProviderContainer in unit tests and ProviderScope overrides in widget tests. You can stub async providers, replace repositories with fakes, and assert on state transitions — without running the full app. Key Takeaways Use ProviderContainer for pure unit tests. It gives you a lightweight scope to
Test Automation
Flutter's built-in integration test framework (package:integration_test) gets you far, but it has a critical blind spot: anything outside the Flutter layer. Native permission dialogs, system notifications, the device keyboard, deep links opened from the browser — these are all invisible to integration_test. Patrol fills that
Flutter
Flutter tests that hit real HTTP endpoints are slow, flaky, and environment-dependent. The solution: inject a fake HTTP client, intercept requests at the Dio layer, or run a lightweight mock server. This guide covers all three approaches with working examples. Key Takeaways Inject http.Client as a dependency. Don&
Test Automation
Golden tests (also called screenshot tests or snapshot tests) capture a widget's rendered output as a PNG and compare it pixel-by-pixel against a stored reference image. They are extraordinarily effective at catching unintended visual regressions — a padding change, a wrong color, a misaligned text node — that
Flutter
Flutter golden tests capture pixel-perfect screenshots of your widgets and fail when the output changes. They are the fastest way to catch visual regressions — a changed color, a broken layout, a clipped text — without manual visual review. This guide covers the full workflow: writing goldens, updating them intentionally, handling
Flutter
Patrol is a Flutter testing framework built on top of integration_test that lets you interact with native UI elements — permission dialogs, notifications, the status bar, deep links — without platform-specific ADB/xcrun hacks. This guide covers setup, writing PatrolTester tests, handling permissions, testing notifications, and running Patrol in CI.
Flutter
Flutter has two end-to-end testing frameworks: the legacy flutter_driver and the modern integration_test package. For new projects, use integration_test — it runs in the same process as your app, works with flutter test, and supports Web and Desktop. flutter_driver remains useful for specific scenarios like
Dart
The test package is Dart's standard testing library — used by both pure Dart projects and Flutter apps. It provides test(), group(), setUp(), tearDown(), async test support, stream matchers, and a rich set of built-in matchers. Everything in Flutter's flutter_test is built on top of
Test Automation
Mocking is the backbone of isolated unit testing. When your UserBloc depends on a UserRepository that hits a network, you don't want real HTTP calls in tests — you want a fake that returns exactly what you tell it to. Dart has two dominant mocking libraries: mockito (the established
Flutter
Mocking lets you replace real dependencies — HTTP clients, databases, sensors — with controlled fakes in tests. Dart has two excellent mocking libraries: Mockito (code-generation-based, type-safe) and Mocktail (no code gen, reflection-based). This guide covers both, with production-ready patterns for when/thenReturn, verify, argument matchers, and stubbing