|
2 | 2 | [](https://pub.dev/packages/test_reflective_loader) |
3 | 3 | [](https://pub.dev/packages/test_reflective_loader/publisher) |
4 | 4 |
|
5 | | -Support for discovering tests and test suites using reflection. |
| 5 | +Support for discovering and running tests and test suites using reflection. |
6 | 6 |
|
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. |
9 | 9 |
|
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 |
13 | 11 |
|
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`. |
15 | 14 |
|
16 | | -Methods with names starting with `fail_` are expected to fail. |
| 15 | +Here is a simple example: |
17 | 16 |
|
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'; |
20 | 20 |
|
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. |
23 | 99 |
|
24 | 100 | ## Features and bugs |
25 | 101 |
|
|
0 commit comments