A communityA useful regression test can distinguish the original failure from the intended behaviour. Review that distinction before treating a green test as sufficient.
State the behavioural contract
Describe the initial widget state, the user action and the visible result. Include a boundary case that is likely to expose the problem: an empty list, the last remaining item, a repeated action or keyboard focus after dismissal.
Flutter’s widget-testing tools provide a test environment for building and interacting with widgets. A finder identifies a widget; an assertion checks an expectation. The result remains a widget-environment result and does not establish native platform behaviour.
Review the test in four passes
- Read the test’s setup and identify what state it creates.
- Check that its actions reproduce the reported sequence.
- Read each assertion as a user-visible promise.
- Ask whether the original implementation would fail that assertion.
| Synthetic scenario | Behaviour to assert | Weak substitute |
|---|---|---|
| Remove the focused row | Focus reaches a surviving control | Only checking that a method ran |
| Close an unchanged dialog | Focus returns to the opener | Only checking that no exception was caught |
| Remove the last item | A usable empty state appears | Only checking the item count variable |
Separate missing evidence from a failure
If the test never ran against the original implementation, mark that comparison as missing. If it passes before and after, it might cover a useful adjacent behaviour, but it has not demonstrated the reported regression. Review the reproduction and the assertion together.
When the issue depends on a real keyboard, native view or platform permission flow, add the relevant target-level evidence separately. Keep the test name, command, exit result and SDK identity in the review record. A passing test should support a stated claim, not replace the explanation of what changed.
Name the behaviour → Reproduce the sequence → Assert the visible result → Check the original failure.
Primary sources
Continue with the next step
Resolve the next specific question
- Choose the right test level for a Flutter regression
Turn a release blocker into a small test matrix: logic, widget behaviour and a target journey.
- Diagnose a widget test that never settles
Separate scheduled frames, unresolved work and an incorrect expectation before increasing a Flutter test timeout.
- Review a Flutter golden difference before accepting it
Distinguish an intended design change from changed fonts, environment or SDK before updating a visual baseline.
- Check accessibility after a Flutter UI change
A regression procedure for labels, focus, text scaling and semantics in a changed Flutter interaction.