dart-test-fundamentals

Name: dart-test-fundamentals
Author: kevmoo

388installs16forks

How to install dart-test-fundamentals?

kevmoo/dash_skills/dart-test-fundamentals

$npx -y skills add kevmoo/dash_skills --skill dart-test-fundamentals

Installs into the current project.

Summary

Core concepts and best practices for package:test. Covers test, group, lifecycle methods (setUp, tearDown), and configuration (dart_test.yaml).

Files · 1

View on GitHub

SKILL.md

1	# Dart Test Fundamentals
2
3	## When to use this skill
4
5	Use this skill when:
6	- Writing new test files.
7	- Structuring test suites with `group`.
8	- Configuring test execution via `dart_test.yaml`.
9	- Understanding test lifecycle methods.
10
11	## Discovery
12
13	To find candidates for improving test structure:
14
15	### `try-finally` Cleanup
16	Search for tests that use `try-finally` for cleanup instead of `addTearDown`:
17	- Regex: `\bfinally\s*\{` (Check if this is used for resource cleanup
18	inside a test).
19
20	## Core Concepts
21
22	### 1. Test Structure (`test` and `group`)
23
24	- `test`: The fundamental unit of testing.
25	```dart
26	test('description', () {
27	// assertions
28	});
29	```
30	- `group`: Used to organize tests into logical blocks.
31	- Groups can be nested.
32	- Descriptions are concatenated (e.g., "Group Description Test Description").
33	- Helps scope `setUp` and `tearDown` calls.
34	- Naming: Use `PascalCase` for groups that correspond to a class name
35	(e.g., `group('MyClient', ...)`).
36	- Avoid Single Groups: Do not wrap all tests in a file with a single
37	`group` call if it's the only one.
38	- NOTE: DO NOT remove groups when doing a cleanup on existing code you
39	didn't create unless explicitly asked to. This can cause a LOT of churn
40	in the DIFF that most engineers won't want!
41
42	- Naming Tests `test('test name here',`:
43	- Avoid redundant "test" prefixes. Use `group` instead.
44	- Include the expected behavior or outcome in the description (e.g.,
45	`'throws StateError'` or `'adds API key to URL'`).
46	- Descriptions should read well when concatenated with their group name.
47
48	- Named Parameters Placement:
49	- For `test` and `group` calls, place named parameters (e.g., `testOn`,
50	`timeout`, `skip`) immediately after the description string, before the
51	callback closure. This improves readability by keeping the test logic last.
52	```dart
53	test('description', testOn: 'vm', () {
54	// assertions
55	});
56	```
57
58	### 2. Lifecycle Methods (`setUp`, `tearDown`)
59
60	- `setUp`: Runs before every `test` in the current `group` (and nested
61	groups).
62	- `tearDown`: Runs after every `test` in the current `group`.
63	- `setUpAll`: Runs once before any test in the group.
64	- `tearDownAll`: Runs once after all tests in the group.
65
66	Best Practice:
67	- Use `setUp` for resetting state to ensure test isolation.
68	- Avoid sharing mutable state between tests without resetting it.
69
70	### 3. Cleaning Up Resources
71
72	- To clean up resources created WITHIN the `test` body, consider using
73	`addTearDown` instead of a `try-finally` block.
74
75	Avoid:
76	```dart
77	test('can create and delete a file', () {
78	final file = File('temp.txt');
79	try {
80	file.writeAsStringSync('hello');
81	expect(file.readAsStringSync(), 'hello');
82	} finally {
83	if (file.existsSync()) file.deleteSync();
84	}
85	});
86	```
87
88	Prefer:
89	```dart
90	test('can create and delete a file', () {
91	final file = File('temp.txt');
92	// Register teardown immediately after resource creation intent
93	addTearDown(() {
94	if (file.existsSync()) file.deleteSync();
95	});
96
97	file.writeAsStringSync('hello');
98	expect(file.readAsStringSync(), 'hello');
99	});
100	```
101
102	### 4. Configuration (`dart_test.yaml`)
103
104	The `dart_test.yaml` file configures the test runner. Common configurations
105	include:
106
107	#### Platforms
108	Define where tests run (vm, chrome, node).
109
110	```yaml
111	platforms:
112	- vm
113	- chrome
114	```
115
116	#### Tags
117	Categorize tests to run specific subsets.
118
119	```yaml
120	tags:
121	integration:
122	timeout: 2x
123	```
124
125	Usage in code:
126	```dart
127	@Tags(['integration'])
128	import 'package:test/test.dart';
129	```
130
131	Running tags:
132	`dart test --tags integration`
133
134	#### Timeouts
135	Set default timeouts for tests.
136
137	```yaml
138	timeouts:
139	2x # Double the default timeout
140	```
141
142	### 5. File Naming
143	- Test files must end in `_test.dart` to be picked up by the test runner.
144	- Place tests in the `test/` directory.
145
146	## Common commands
147
148	- `dart test`: Run all tests.
149	- `dart test test/path/to/file_test.dart`: Run a specific file.
150	- `dart test --name "substring"`: Run tests matching a description.
151
152	## Related Skills
153
154	`dart-test-fundamentals` is the core skill for structuring and configuring
155	tests. For writing assertions within those tests, refer to:
156
157	- [dart-matcher-best-practices]:
158	Use this if the project sticks with the traditional
159	`package:matcher` (`expect` calls).
160
161	[dart-matcher-best-practices]: https://github.com/kevmoo/dash_skills/blob/main/skills/dart-matcher-best-practices/SKILL.md

People who liked this also viewed

6 picks

Type

tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026501k181k
test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026175k259k
qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026153k259k
webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026120k163k
playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 202664k338

dart-test-fundamentals

388installs16forks

View on GitHub

How to install dart-test-fundamentals?

kevmoo/dash_skills/dart-test-fundamentals

$npx -y skills add kevmoo/dash_skills --skill dart-test-fundamentals

Installs into the current project.

Summary

Core concepts and best practices for package:test. Covers test, group, lifecycle methods (setUp, tearDown), and configuration (dart_test.yaml).

Files · 1

View on GitHub

SKILL.md

1	# Dart Test Fundamentals
2
3	## When to use this skill
4
5	Use this skill when:
6	- Writing new test files.
7	- Structuring test suites with `group`.
8	- Configuring test execution via `dart_test.yaml`.
9	- Understanding test lifecycle methods.
10
11	## Discovery
12
13	To find candidates for improving test structure:
14
15	### `try-finally` Cleanup
16	Search for tests that use `try-finally` for cleanup instead of `addTearDown`:
17	- Regex: `\bfinally\s*\{` (Check if this is used for resource cleanup
18	inside a test).
19
20	## Core Concepts
21
22	### 1. Test Structure (`test` and `group`)
23
24	- `test`: The fundamental unit of testing.
25	```dart
26	test('description', () {
27	// assertions
28	});
29	```
30	- `group`: Used to organize tests into logical blocks.
31	- Groups can be nested.
32	- Descriptions are concatenated (e.g., "Group Description Test Description").
33	- Helps scope `setUp` and `tearDown` calls.
34	- Naming: Use `PascalCase` for groups that correspond to a class name
35	(e.g., `group('MyClient', ...)`).
36	- Avoid Single Groups: Do not wrap all tests in a file with a single
37	`group` call if it's the only one.
38	- NOTE: DO NOT remove groups when doing a cleanup on existing code you
39	didn't create unless explicitly asked to. This can cause a LOT of churn
40	in the DIFF that most engineers won't want!
41
42	- Naming Tests `test('test name here',`:
43	- Avoid redundant "test" prefixes. Use `group` instead.
44	- Include the expected behavior or outcome in the description (e.g.,
45	`'throws StateError'` or `'adds API key to URL'`).
46	- Descriptions should read well when concatenated with their group name.
47
48	- Named Parameters Placement:
49	- For `test` and `group` calls, place named parameters (e.g., `testOn`,
50	`timeout`, `skip`) immediately after the description string, before the
51	callback closure. This improves readability by keeping the test logic last.
52	```dart
53	test('description', testOn: 'vm', () {
54	// assertions
55	});
56	```
57
58	### 2. Lifecycle Methods (`setUp`, `tearDown`)
59
60	- `setUp`: Runs before every `test` in the current `group` (and nested
61	groups).
62	- `tearDown`: Runs after every `test` in the current `group`.
63	- `setUpAll`: Runs once before any test in the group.
64	- `tearDownAll`: Runs once after all tests in the group.
65
66	Best Practice:
67	- Use `setUp` for resetting state to ensure test isolation.
68	- Avoid sharing mutable state between tests without resetting it.
69
70	### 3. Cleaning Up Resources
71
72	- To clean up resources created WITHIN the `test` body, consider using
73	`addTearDown` instead of a `try-finally` block.
74
75	Avoid:
76	```dart
77	test('can create and delete a file', () {
78	final file = File('temp.txt');
79	try {
80	file.writeAsStringSync('hello');
81	expect(file.readAsStringSync(), 'hello');
82	} finally {
83	if (file.existsSync()) file.deleteSync();
84	}
85	});
86	```
87
88	Prefer:
89	```dart
90	test('can create and delete a file', () {
91	final file = File('temp.txt');
92	// Register teardown immediately after resource creation intent
93	addTearDown(() {
94	if (file.existsSync()) file.deleteSync();
95	});
96
97	file.writeAsStringSync('hello');
98	expect(file.readAsStringSync(), 'hello');
99	});
100	```
101
102	### 4. Configuration (`dart_test.yaml`)
103
104	The `dart_test.yaml` file configures the test runner. Common configurations
105	include:
106
107	#### Platforms
108	Define where tests run (vm, chrome, node).
109
110	```yaml
111	platforms:
112	- vm
113	- chrome
114	```
115
116	#### Tags
117	Categorize tests to run specific subsets.
118
119	```yaml
120	tags:
121	integration:
122	timeout: 2x
123	```
124
125	Usage in code:
126	```dart
127	@Tags(['integration'])
128	import 'package:test/test.dart';
129	```
130
131	Running tags:
132	`dart test --tags integration`
133
134	#### Timeouts
135	Set default timeouts for tests.
136
137	```yaml
138	timeouts:
139	2x # Double the default timeout
140	```
141
142	### 5. File Naming
143	- Test files must end in `_test.dart` to be picked up by the test runner.
144	- Place tests in the `test/` directory.
145
146	## Common commands
147
148	- `dart test`: Run all tests.
149	- `dart test test/path/to/file_test.dart`: Run a specific file.
150	- `dart test --name "substring"`: Run tests matching a description.
151
152	## Related Skills
153
154	`dart-test-fundamentals` is the core skill for structuring and configuring
155	tests. For writing assertions within those tests, refer to:
156
157	- [dart-matcher-best-practices]:
158	Use this if the project sticks with the traditional
159	`package:matcher` (`expect` calls).
160
161	[dart-matcher-best-practices]: https://github.com/kevmoo/dash_skills/blob/main/skills/dart-matcher-best-practices/SKILL.md

People who liked this also viewed

6 picks

Type