Unit and golden tests
Unit tests cover Dart code independent of Flutter: repositories, view models and cubits, calculations, validation rules. They run in milliseconds, which is why most of your tests belong at this level.
Dependencies are substituted. Two ways:
- Hand-written fakes — the most readable option for a small interface
- A mocking library (
mocktail) — when you need call verification (verify) or complex behaviour
For simple cases a hand-written fake reads better than a mock, and saying so in an interview shows balanced judgement.
Golden tests (screenshot tests) compare a widget's appearance against a reference image. They catch visual regressions: colour, spacing, font and layout changes.
Where they shine: design-system components — if a button's appearance changes accidentally, the test catches it.
Their real pain: cross-platform differences. Font rendering differs between macOS, Linux and CI, so a golden that passes locally can fail in CI. The practical fix: generate goldens in the same environment as CI (usually a Docker container) and load fonts explicitly in the test.
Interview tip. If golden tests come up, pair the benefit with the cost. They catch visual regressions, but they produce false positives and need regenerating on every design change. My recommendation: use goldens for design-system components rather than whole screens — screen goldens go stale fast, the team starts regenerating them without looking, and the test stops meaning anything.
📚 Sources and documentation
- Introduction to unit testingofficialdocs.flutter.dev
- Testing Flutter appsofficialdocs.flutter.dev
- mocktail packagepub.dev
Creating mocks without code generation, and using `verify`, are covered in the README.