Skip to content

Commit e1b1b4c

Browse files
authored
Improve test_reflective_loader/README.md (#2129)
1 parent fd7cc89 commit e1b1b4c

File tree

1 file changed

+88
-12
lines changed

1 file changed

+88
-12
lines changed

pkgs/test_reflective_loader/README.md

Lines changed: 88 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -2,24 +2,100 @@
22
[![pub package](https://img.shields.io/pub/v/test_reflective_loader.svg)](https://pub.dev/packages/test_reflective_loader)
33
[![package publisher](https://img.shields.io/pub/publisher/test_reflective_loader.svg)](https://pub.dev/packages/test_reflective_loader/publisher)
44

5-
Support for discovering tests and test suites using reflection.
5+
Support for discovering and running tests and test suites using reflection.
66

7-
This package follows the xUnit style where each class is a test suite, and each
8-
method with the name prefix `test_` is a single test.
7+
This package follows an xUnit style where each class can be a test suite.
8+
Test methods within the class are discovered reflectively based on their names or annotations.
99

10-
Methods with names starting with `test_` are run using the `test()` function with
11-
the corresponding name. If the class defines methods `setUp()` or `tearDown()`,
12-
they are executed before / after each test correspondingly, even if the test fails.
10+
## Usage
1311

14-
Methods with names starting with `solo_test_` are run using the `solo_test()` function.
12+
A test file will typically have a `main` function that kicks off the test loader, and one or more classes annotated with
13+
`@reflectiveTest`.
1514

16-
Methods with names starting with `fail_` are expected to fail.
15+
Here is a simple example:
1716

18-
Methods with names starting with `solo_fail_` are run using the `solo_test()` function
19-
and expected to fail.
17+
```dart
18+
import 'package:test/test.dart';
19+
import 'package:test_reflective_loader/test_reflective_loader.dart';
2020
21-
Method returning `Future` class instances are asynchronous, so `tearDown()` is
22-
executed after the returned `Future` completes.
21+
void main() {
22+
defineReflectiveSuite(() {
23+
defineReflectiveTests(MyTestClass);
24+
});
25+
}
26+
27+
@reflectiveTest
28+
class MyTestClass {
29+
void test_simpleSuccess() {
30+
expect(true, isTrue);
31+
}
32+
33+
@failingTest
34+
void test_expectedToFail() {
35+
expect(false, isTrue);
36+
}
37+
38+
@skippedTest
39+
void test_skipped() {
40+
// This test won't be run.
41+
}
42+
43+
void setUp() {
44+
// setUp is called before each test.
45+
print('setting up');
46+
}
47+
48+
void tearDown() {
49+
// tearDown is called after each test.
50+
print('tearing down');
51+
}
52+
}
53+
```
54+
55+
To run the tests, you would execute your test file with `dart test`.
56+
57+
### Test Discovery
58+
59+
The `defineReflectiveSuite` and `defineReflectiveTests` functions are used to discover and define tests.
60+
61+
* `defineReflectiveSuite`: This function creates a test suite. It takes a closure as an argument, and within that
62+
closure, you can define tests and other nested suites. This allows you to group related tests together.
63+
64+
* `defineReflectiveTests`: This function tells the test runner to look for tests in a given class. The class must be
65+
annotated with `@reflectiveTest`. The test runner will then reflectively look for methods in that class that are
66+
considered tests (see below).
67+
68+
### Test Suites
69+
70+
Test suites are classes annotated with `@reflectiveTest`. The loader will instantiate this class for each test method,
71+
so tests are isolated from each other.
72+
73+
### Test Methods
74+
75+
The loader discovers tests in a few ways:
76+
77+
* Methods whose names start with `test_` are treated as tests.
78+
* Methods whose names start with `fail_` are treated as tests that are expected to fail.
79+
* Methods whose names start with `skip_` are skipped.
80+
81+
### Annotations
82+
83+
* `@failingTest`: Marks a test that is expected to fail. This is useful for tests that demonstrate a bug that has not
84+
yet been fixed.
85+
* `@skippedTest`: Marks a test that should be skipped and not run.
86+
* `@soloTest`: Can be applied to a test class or a test method to indicate that only this test (or the tests in this
87+
class) should be run. If multiple tests/classes have this annotation, they will all run.
88+
89+
### `setUp` and `tearDown`
90+
91+
If a test class defines a `setUp()` method, it will be run before each test method in that class. If it defines a
92+
`tearDown()` method, it will be run after each test method, even if the test fails. These are useful for setting up and
93+
cleaning up test fixtures. Both `setUp()` and `tearDown()` can be `async` and return a `Future`.
94+
95+
### Asynchronous Tests
96+
97+
If a test method, `setUp()`, or `tearDown()` returns a `Future`, the test runner will wait for the future to complete.
98+
The `tearDown` method (if any) will be executed after the test method and its `Future` completes.
2399

24100
## Features and bugs
25101

0 commit comments

Comments
 (0)