Question 1

What kinds of tests exist in Flutter and when do you write each?

Accepted Answer

Three levels: unit — business logic without Flutter, running in milliseconds; these are the bulk of what I write. Widget — one screen or component without a device, verifying user interaction and how state changes reach the UI; the best cost/benefit balance. Integration — the whole app on a real device; slow and more fragile, so reserved for critical flows like sign-in and payment. The pyramid principle holds in Flutter too: many unit, a moderate number of widget, few integration. With my QA background I would add: I verify each thing at the lowest level that can prove it.

Question 2

What is the difference between pump and pumpAndSettle?

Accepted Answer

pump() advances one frame — enough to see the UI update after a setState. pump(Duration) advances by a given time — for checking a specific point in an animation or letting a future resolve. pumpAndSettle() pumps until no animation remains, which is convenient across screen transitions. The key trap: with an endless animation — a CircularProgressIndicator that never stops — pumpAndSettle never returns and the test times out. On such screens I use an explicit pump(Duration(...)); knowing that detail is a mark of real experience.

Question 3

What should a widget test assert on?

Accepted Answer

Behaviour, not implementation. find.text('Order created') checks what the user sees and keeps working even when the screen's internal structure changes. find.byType(Padding) is tied to implementation: a design tweak breaks the test for no real reason and it proved nothing anyway. It is the same principle as locator choice in Playwright — user-facing selectors are durable, structural chains are brittle. For dynamic or text-free elements I use a Key, but as a convention agreed with the dev team, since retrofitting keys is painful.

Question 4

If a Flutter test is flaky, what are the likely causes?

Accepted Answer

The four most common causes: (1) not pumping enough — the UI has not updated yet but the assertion runs; fixed with the right pump/pumpAndSettle. (2) Dependence on real time — Future.delayed or DateTime.now(); use fakeAsync or an injected clock. (3) Real network or I/O — always substitute a fake. (4) State shared between tests — a global singleton, the getIt registry; reset after each test. My diagnostic: run the test repeatedly with --repeat, and if it fails intermittently I work down that list from the top.

Widget testing

📚 Sources and documentation