Dart test fundamentals
Core concepts and best practices for `package:test`. Covers `test`, `group`, lifecycle methods (`setUp`, `tearDown`), and configuration (`dart_test.yaml`).From its SKILL.md
npx -y skills add kevmoo/dash_skills --skill dart-test-fundamentalsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its file declares
Copied from the file, not written here
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
4.7 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
Dart Test Fundamentals
When to use this skill
Use this skill when:
- Writing new test files.
- Structuring test suites with
group. - Configuring test execution via
dart_test.yaml. - Understanding test lifecycle methods.
Discovery
To find candidates for improving test structure:
try-finally Cleanup
Search for tests that use try-finally for cleanup instead of addTearDown:
- Regex:
\bfinally\s*\{(Check if this is used for resource cleanup inside a test).
Core Concepts
1. Test Structure (test and group)
-
test: The fundamental unit of testing.test('description', () { // assertions }); -
group: Used to organize tests into logical blocks.- Groups can be nested.
- Descriptions are concatenated (e.g., "Group Description Test Description").
- Helps scope
setUpandtearDowncalls. - Naming: Use
PascalCasefor groups that correspond to a class name (e.g.,group('MyClient', ...)). - Avoid Single Groups: Do not wrap all tests in a file with a single
groupcall if it's the only one.- NOTE: DO NOT remove groups when doing a cleanup on existing code you didn't create unless explicitly asked to. This can cause a LOT of churn in the DIFF that most engineers won't want!
-
Naming Tests
test('test name here',:- Avoid redundant "test" prefixes. Use
groupinstead. - Include the expected behavior or outcome in the description (e.g.,
'throws StateError'or'adds API key to URL'). - Descriptions should read well when concatenated with their group name.
- Avoid redundant "test" prefixes. Use
-
Named Parameters Placement:
- For
testandgroupcalls, place named parameters (e.g.,testOn,timeout,skip) immediately after the description string, before the callback closure. This improves readability by keeping the test logic last.test('description', testOn: 'vm', () { // assertions });
- For
2. Lifecycle Methods (setUp, tearDown)
setUp: Runs before everytestin the currentgroup(and nested groups).tearDown: Runs after everytestin the currentgroup.setUpAll: Runs once before any test in the group.tearDownAll: Runs once after all tests in the group.
Best Practice:
- Use
setUpfor resetting state to ensure test isolation. - Avoid sharing mutable state between tests without resetting it.
3. Cleaning Up Resources
- To clean up resources created WITHIN the
testbody, consider usingaddTearDowninstead of atry-finallyblock.
Avoid:
test('can create and delete a file', () {
final file = File('temp.txt');
try {
file.writeAsStringSync('hello');
expect(file.readAsStringSync(), 'hello');
} finally {
if (file.existsSync()) file.deleteSync();
}
});
Prefer:
test('can create and delete a file', () {
final file = File('temp.txt');
// Register teardown immediately after resource creation intent
addTearDown(() {
if (file.existsSync()) file.deleteSync();
});
file.writeAsStringSync('hello');
expect(file.readAsStringSync(), 'hello');
});
4. Configuration (dart_test.yaml)
The dart_test.yaml file configures the test runner. Common configurations
include:
Platforms
Define where tests run (vm, chrome, node).
platforms:
- vm
- chrome
Tags
Categorize tests to run specific subsets.
tags:
integration:
timeout: 2x
Usage in code:
@Tags(['integration'])
import 'package:test/test.dart';
Running tags:
dart test --tags integration
Timeouts
Set default timeouts for tests.
timeouts:
2x # Double the default timeout
5. File Naming
- Test files must end in
_test.dartto be picked up by the test runner. - Place tests in the
test/directory.
Common commands
dart test: Run all tests.dart test test/path/to/file_test.dart: Run a specific file.dart test --name "substring": Run tests matching a description.
Related Skills
dart-test-fundamentals is the core skill for structuring and configuring
tests. For writing assertions within those tests, refer to:
- dart-matcher-best-practices:
Use this if the project sticks with the traditional
package:matcher(expectcalls).
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most project setup skills give in ~1.1k tokens
Counted across 1,553 of the 3,091 authors here whose files we hold, read 2026-09-06
- Write the configuration filein 36 of 1553
- Create the directory structurein 35 of 1553, across 33 files
- Verify the setupin 31 of 1553, across 28 files
- Run the setup scriptin 30 of 1553, across 29 files
- Pre-determine the required sample sizein 29 of 1553, across 12 files
- Check if the configuration already existsin 29 of 1553
- Document every testin 26 of 1553, across 10 files
- Start with a hypothesisin 26 of 1553, across 11 files
- Ask one question at a timein 22 of 1553
- Test a single variable per testin 21 of 1553, across 9 files
- Read product marketing context before asking questionsin 19 of 1553, across 8 files
- Do not peek and stop earlyin 18 of 1553, across 7 files
Said here and by no other author read
- Use test and group for structure
- Use PascalCase for class groups
- Avoid single unnecessary groups
- Place named parameters before callback
- Use setUp for resetting state
- Use addTearDown for resource cleanup
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.