Integration testing and CI
Integration tests run the whole app on a real device or emulator: real navigation, real platform channels, often a real backend. They are written with the integration_test package and read much like widget tests — the difference is the execution environment.
When you need them:
- Critical flows — sign-in, payment, registration: proving they work end to end
- Platform integration — permissions, camera, notifications: not verifiable in a widget test
- Real performance measurement — frame timings on a device
When you do not: for covering every case. Integration tests are slow (minutes) and more fragile because of network and device dependencies — the top of the pyramid should stay small.
In CI integration tests need separate planning:
- An emulator or simulator has to be provisioned — the hardest part of the CI configuration
- Unit and widget tests run on every PR, while integration tests usually run after merge or nightly, because a 15-minute wait on a PR blocks developer flow
- Artifacts (screenshots, video, logs) should be retained on failure
A typical Flutter CI sequence: flutter analyze → flutter test (unit + widget) → build → integration.
Managing flaky integration tests takes its own discipline: quarantine, root-cause analysis and an SLA — the same principles as with a Playwright suite.
Interview tip. With a QA background you may be pushed further here. Show a test strategy: what you verify at which level and why. Give a concrete example — "payment calculation in a unit test, the payment screen's states in a widget test, and one end-to-end integration test for the payment flow". That three-layer explanation is far stronger than a one-line answer.
📚 Sources and documentation
- Introduction to integration testingofficialdocs.flutter.dev
- integration_test packageofficialpub.dev
- Testing Flutter appsofficialdocs.flutter.dev
- Testing pluginsofficialdocs.flutter.dev