In Dart's package:test, how do test, group, setUp, tearDown and setUpAll organise a suite, and in what order do the hooks run?

## The building blocks `package:test` is the standard Dart test framework, used directly for Dart packages and underneath `flutter_test` for Flutter. A test file is an ordinary Dart program whose `main()` **declares** tests; the runner then executes them. - **`test(description, body)`** declares one test case. `body` can return a `Future`; the runner waits for it. - **`group(description, body)`** nests tests. The group's description is prepended to every test inside it, and hooks declared inside apply only to that group. - **`expect(actual, matcher)`** asserts; a plain value as `matcher` is wrapped in `equals`. ```dart import 'package:test/test.dart'; import 'package:dates/dates.dart'; void main() { group('IsoDateParser', () { late IsoDateParser parser; setUp(() => parser = IsoDateParser()); test('parses a calendar date', () { expect(parser.parse('2026-09-29'), equals(DateTime(2026, 9, 29))); }); test('keeps the UTC flag for a Z suffix', () { expect(parser.parse('2026-09-29T10:00:00Z').isUtc, isTrue); }); }); } ``` The report shows `IsoDateParser parses a calendar date`, which is why group names are nouns and test names read as behaviour. ## The four hooks and their order | Hook | Runs | Order among several | |---|---|---| | `setUp` | before each test in its group | parent groups first, then declaration order | | `tearDown` | after each test, **even if it failed** | own group before parents, reverse declaration order | | `setUpAll` | once before the group's first test | parent groups first | | `tearDownAll` | once after the group's last test | own group before parents | For a test nested two groups deep, the sequence is: 1. top-level `setUp` callbacks; 2. outer group `setUp`; 3. inner group `setUp`; 4. the test body; 5. any `addTearDown` callbacks, most recent first; 6. inner group `tearDown`; 7. outer group `tearDown`; 8. top-level `tearDown`. `setUpAll` and `tearDownAll` wrap the whole group once and **do not run if none of the group's tests run**, for example when a name filter excludes them all. ## addTearDown `addTearDown(callback)` is called **inside** a running test (or a helper it calls). It registers cleanup for that test only, runs **before** the `tearDown` callbacks, and follows last-in, first-out order. It is the tidy choice when a helper creates a resource halfway through a test: ```dart // needs import 'dart:io'; test('reads dates from a temp file', () async { final dir = await Directory.systemTemp.createTemp(); addTearDown(() => dir.delete(recursive: true)); // ... }); ``` Calling it outside a test throws a `StateError`. Called from `setUpAll` or `tearDownAll`, it runs after all tests in the suite instead. ## Why setUp beats setUpAll by default `setUp` gives each test a **fresh** fixture, so tests cannot affect each other and can run in any order. `setUpAll` shares one fixture across a group, which is faster for expensive resources (a database file, a spawned process) but lets one test's mutation leak into the next. package:test's own documentation recommends `setUp` and reserves `setUpAll` for callbacks that are prohibitively slow. Shared state of this kind is what the runner's `--test-randomize-ordering-seed` option, which shuffles test order, is good at exposing. ## Where tests live - The `test` package is a **dev dependency**. - Files end in `_test.dart` and live under `test/`; `dart test` with no path finds them recursively. - Run one file with `dart test test/iso_date_parser_test.dart`. ## Mistakes interviewers look for - Declaring shared state as a top-level `final` initialised once, instead of resetting it in `setUp`. - Assuming `tearDown` is skipped when a test fails, and putting cleanup at the end of the test body instead. - Nesting groups only for indentation, while hooks in them unexpectedly apply to every test inside. ## A worked layout for a date library A test file for a date-parsing library usually mirrors the public API: 1. a top-level `group('IsoDateParser', ...)` with a `setUp` that creates a fresh parser; 2. nested groups per behaviour, such as `group('calendar dates', ...)` and `group('rejects', ...)`, so failures read `IsoDateParser rejects month 13`; 3. a `setUpAll` only for something expensive and read-only, such as loading a large table of time-zone rules from disk; 4. `addTearDown` inside the few tests that create temporary files. Keeping hooks close to the tests that need them means a reader sees the whole context of a failing test within one screen, and `dart test -n "IsoDateParser rejects"` runs exactly one behaviour. ## Where package:test stops The framework gives structure, assertions and a runner. Choosing what a unit is, how to name behaviour, and how to arrange a test body are general testing questions; in Flutter projects, `testWidgets` adds a widget tester on top of the same `group`, `setUp` and `expect`.