| OLD | NEW |
| (Empty) | |
| 1 **TODO: Add more examples to cover all of the syntax.** |
| 2 |
| 3 This input was taken from the test package's README to get a representative |
| 4 sample of real-world markdown: |
| 5 |
| 6 ## Writing Tests |
| 7 |
| 8 Tests are specified using the top-level [`test()`][test] function, and test |
| 9 assertions are made using [`expect()`][expect]: |
| 10 |
| 11 [test]: http://www.dartdocs.org/documentation/test/latest/index.html#test/test@i
d_test |
| 12 [expect]: http://www.dartdocs.org/documentation/test/latest/index.html#test/test
@id_expect |
| 13 |
| 14 ```dart |
| 15 import "package:test/test.dart"; |
| 16 |
| 17 void main() { |
| 18 test("String.split() splits the string on the delimiter", () { |
| 19 var string = "foo,bar,baz"; |
| 20 expect(string.split(","), equals(["foo", "bar", "baz"])); |
| 21 }); |
| 22 |
| 23 test("String.trim() removes surrounding whitespace", () { |
| 24 var string = " foo "; |
| 25 expect(string.trim(), equals("foo")); |
| 26 }); |
| 27 } |
| 28 ``` |
| 29 |
| 30 Tests can be grouped together using the [`group()`] function. Each group's |
| 31 description is added to the beginning of its test's descriptions. |
| 32 |
| 33 ```dart |
| 34 import "package:test/test.dart"; |
| 35 |
| 36 void main() { |
| 37 group("String", () { |
| 38 test(".split() splits the string on the delimiter", () { |
| 39 var string = "foo,bar,baz"; |
| 40 expect(string.split(","), equals(["foo", "bar", "baz"])); |
| 41 }); |
| 42 |
| 43 test(".trim() removes surrounding whitespace", () { |
| 44 var string = " foo "; |
| 45 expect(string.trim(), equals("foo")); |
| 46 }); |
| 47 }); |
| 48 |
| 49 group("int", () { |
| 50 test(".remainder() returns the remainder of division", () { |
| 51 expect(11.remainder(3), equals(2)); |
| 52 }); |
| 53 |
| 54 test(".toRadixString() returns a hex string", () { |
| 55 expect(11.toRadixString(16), equals("b")); |
| 56 }); |
| 57 }); |
| 58 } |
| 59 ``` |
| 60 |
| 61 Any matchers from the [`matcher`][matcher] package can be used with `expect()` |
| 62 to do complex validations: |
| 63 |
| 64 [matcher]: http://www.dartdocs.org/documentation/matcher/latest/index.html#match
er/matcher |
| 65 |
| 66 ```dart |
| 67 import "package:test/test.dart"; |
| 68 |
| 69 void main() { |
| 70 test(".split() splits the string on the delimiter", () { |
| 71 expect("foo,bar,baz", allOf([ |
| 72 contains("foo"), |
| 73 isNot(startsWith("bar")), |
| 74 endsWith("baz") |
| 75 ])); |
| 76 }); |
| 77 } |
| 78 ``` |
| 79 |
| 80 ## Running Tests |
| 81 |
| 82 A single test file can be run just using `pub run test:test path/to/test.dart` |
| 83 (on Dart 1.10, this can be shortened to `pub run test path/to/test.dart`). |
| 84 |
| 85  |
| 86 |
| 87 Many tests can be run at a time using `pub run test:test path/to/dir`. |
| 88 |
| 89  |
| 90 |
| 91 It's also possible to run a test on the Dart VM only by invoking it using `dart |
| 92 path/to/test.dart`, but this doesn't load the full test runner and will be |
| 93 missing some features. |
| 94 |
| 95 The test runner considers any file that ends with `_test.dart` to be a test |
| 96 file. If you don't pass any paths, it will run all the test files in your |
| 97 `test/` directory, making it easy to test your entire application at once. |
| 98 |
| 99 By default, tests are run in the Dart VM, but you can run them in the browser as |
| 100 well by passing `pub run test:test -p chrome path/to/test.dart`. |
| 101 `test` will take care of starting the browser and loading the tests, and all |
| 102 the results will be reported on the command line just like for VM tests. In |
| 103 fact, you can even run tests on both platforms with a single command: `pub run |
| 104 test:test -p "chrome,vm" path/to/test.dart`. |
| 105 |
| 106 ### Restricting Tests to Certain Platforms |
| 107 |
| 108 Some test files only make sense to run on particular platforms. They may use |
| 109 `dart:html` or `dart:io`, they might test Windows' particular filesystem |
| 110 behavior, or they might use a feature that's only available in Chrome. The |
| 111 [`@TestOn`][TestOn] annotation makes it easy to declare exactly which platforms |
| 112 a test file should run on. Just put it at the top of your file, before any |
| 113 `library` or `import` declarations: |
| 114 |
| 115 ```dart |
| 116 @TestOn("vm") |
| 117 |
| 118 import "dart:io"; |
| 119 |
| 120 import "package:test/test.dart"; |
| 121 |
| 122 void main() { |
| 123 // ... |
| 124 } |
| 125 ``` |
| 126 |
| 127 [TestOn]: http://www.dartdocs.org/documentation/test/latest/index.html#test/test
.TestOn |
| 128 |
| 129 The string you pass to `@TestOn` is what's called a "platform selector", and it |
| 130 specifies exactly which platforms a test can run on. It can be as simple as the |
| 131 name of a platform, or a more complex Dart-like boolean expression involving |
| 132 these platform names. |
| 133 |
| 134 ### Platform Selector Syntax |
| 135 |
| 136 Platform selectors can contain identifiers, parentheses, and operators. When |
| 137 loading a test, each identifier is set to `true` or `false` based on the current |
| 138 platform, and the test is only loaded if the platform selector returns `true`. |
| 139 The operators `||`, `&&`, `!`, and `? :` all work just like they do in Dart. The |
| 140 valid identifiers are: |
| 141 |
| 142 * `vm`: Whether the test is running on the command-line Dart VM. |
| 143 |
| 144 * `dartium`: Whether the test is running on Dartium. |
| 145 |
| 146 * `content-shell`: Whether the test is running on the headless Dartium content |
| 147 shell. |
| 148 |
| 149 * `chrome`: Whether the test is running on Google Chrome. |
| 150 |
| 151 * `phantomjs`: Whether the test is running on |
| 152 [PhantomJS](http://phantomjs.org/). |
| 153 |
| 154 * `firefox`: Whether the test is running on Mozilla Firefox. |
| 155 |
| 156 * `safari`: Whether the test is running on Apple Safari. |
| 157 |
| 158 * `ie`: Whether the test is running on Microsoft Internet Explorer. |
| 159 |
| 160 * `dart-vm`: Whether the test is running on the Dart VM in any context, |
| 161 including Dartium. It's identical to `!js`. |
| 162 |
| 163 * `browser`: Whether the test is running in any browser. |
| 164 |
| 165 * `js`: Whether the test has been compiled to JS. This is identical to |
| 166 `!dart-vm`. |
| 167 |
| 168 * `blink`: Whether the test is running in a browser that uses the Blink |
| 169 rendering engine. |
| 170 |
| 171 * `windows`: Whether the test is running on Windows. If `vm` is false, this will |
| 172 be `false` as well. |
| 173 |
| 174 * `mac-os`: Whether the test is running on Mac OS. If `vm` is false, this will |
| 175 be `false` as well. |
| 176 |
| 177 * `linux`: Whether the test is running on Linux. If `vm` is false, this will be |
| 178 `false` as well. |
| 179 |
| 180 * `android`: Whether the test is running on Android. If `vm` is false, this will |
| 181 be `false` as well, which means that this *won't* be true if the test is |
| 182 running on an Android browser. |
| 183 |
| 184 * `posix`: Whether the test is running on a POSIX operating system. This is |
| 185 equivalent to `!windows`. |
| 186 |
| 187 For example, if you wanted to run a test on every browser but Chrome, you would |
| 188 write `@TestOn("browser && !chrome")`. |
| 189 |
| 190 ### Running Tests on Dartium |
| 191 |
| 192 Tests can be run on [Dartium][] by passing the `-p dartium` flag. If you're |
| 193 using the Dart Editor, the test runner will be able to find Dartium |
| 194 automatically. On Mac OS, you can also [install it using Homebrew][homebrew]. |
| 195 Otherwise, make sure there's an executable called `dartium` (on Mac OS or Linux) |
| 196 or `dartium.exe` (on Windows) on your system path. |
| 197 |
| 198 [Dartium]: https://www.dartlang.org/tools/dartium/ |
| 199 [homebrew]: https://github.com/dart-lang/homebrew-dart |
| 200 |
| 201 Similarly, tests can be run on the headless Dartium content shell by passing `-p |
| 202 content-shell`. The content shell is installed along with Dartium when using |
| 203 Homebrew. Otherwise, you can downloaded it manually [from this |
| 204 page][content_shell]; if you do, make sure the executable named `content_shell` |
| 205 (on Mac OS or Linux) or `content_shell.exe` (on Windows) is on your system path. |
| 206 |
| 207 [content_shell]: http://gsdview.appspot.com/dart-archive/channels/stable/release
/latest/dartium/ |
| 208 |
| 209 [In the future][issue 63], there will be a more explicit way to configure the |
| 210 location of both the Dartium and content shell executables. |
| 211 |
| 212 [issue 63]: https://github.com/dart-lang/test/issues/63 |
| 213 |
| 214 ## Asynchronous Tests |
| 215 |
| 216 Tests written with `async`/`await` will work automatically. The test runner |
| 217 won't consider the test finished until the returned `Future` completes. |
| 218 |
| 219 ```dart |
| 220 import "dart:async"; |
| 221 |
| 222 import "package:test/test.dart"; |
| 223 |
| 224 void main() { |
| 225 test("new Future.value() returns the value", () async { |
| 226 var value = await new Future.value(10); |
| 227 expect(value, equals(10)); |
| 228 }); |
| 229 } |
| 230 ``` |
| 231 |
| 232 There are also a number of useful functions and matchers for more advanced |
| 233 asynchrony. The [`completion()`][completion] matcher can be used to test |
| 234 `Futures`; it ensures that the test doesn't finish until the `Future` completes, |
| 235 and runs a matcher against that `Future`'s value. |
| 236 |
| 237 [completion]: http://www.dartdocs.org/documentation/test/latest/index.html#test/
test@id_completion |
| 238 |
| 239 ```dart |
| 240 import "dart:async"; |
| 241 |
| 242 import "package:test/test.dart"; |
| 243 |
| 244 void main() { |
| 245 test("new Future.value() returns the value", () { |
| 246 expect(new Future.value(10), completion(equals(10))); |
| 247 }); |
| 248 } |
| 249 ``` |
| 250 |
| 251 The [`throwsA()`][throwsA] matcher and the various `throwsExceptionType` |
| 252 matchers work with both synchronous callbacks and asynchronous `Future`s. They |
| 253 ensure that a particular type of exception is thrown: |
| 254 |
| 255 [throwsA]: http://www.dartdocs.org/documentation/test/latest/index.html#test/tes
t@id_throwsA |
| 256 |
| 257 ```dart |
| 258 import "dart:async"; |
| 259 |
| 260 import "package:test/test.dart"; |
| 261 |
| 262 void main() { |
| 263 test("new Future.error() throws the error", () { |
| 264 expect(new Future.error("oh no"), throwsA(equals("oh no"))); |
| 265 expect(new Future.error(new StateError("bad state")), throwsStateError); |
| 266 }); |
| 267 } |
| 268 ``` |
| 269 |
| 270 The [`expectAsync()`][expectAsync] function wraps another function and has two |
| 271 jobs. First, it asserts that the wrapped function is called a certain number of |
| 272 times, and will cause the test to fail if it's called too often; second, it |
| 273 keeps the test from finishing until the function is called the requisite number |
| 274 of times. |
| 275 |
| 276 ```dart |
| 277 import "dart:async"; |
| 278 |
| 279 import "package:test/test.dart"; |
| 280 |
| 281 void main() { |
| 282 test("Stream.fromIterable() emits the values in the iterable", () { |
| 283 var stream = new Stream.fromIterable([1, 2, 3]); |
| 284 |
| 285 stream.listen(expectAsync((number) { |
| 286 expect(number, inInclusiveRange(1, 3)); |
| 287 }, count: 3)); |
| 288 }); |
| 289 } |
| 290 ``` |
| 291 |
| 292 [expectAsync]: http://www.dartdocs.org/documentation/test/latest/index.html#test
/test@id_expectAsync |
| 293 |
| 294 ## Running Tests with Custom HTML |
| 295 |
| 296 By default, the test runner will generate its own empty HTML file for browser |
| 297 tests. However, tests that need custom HTML can create their own files. These |
| 298 files have three requirements: |
| 299 |
| 300 * They must have the same name as the test, with `.dart` replaced by `.html`. |
| 301 |
| 302 * They must contain a `link` tag with `rel="x-dart-test"` and an `href` |
| 303 attribute pointing to the test script. |
| 304 |
| 305 * They must contain `<script src="packages/test/dart.js"></script>`. |
| 306 |
| 307 For example, if you had a test called `custom_html_test.dart`, you might write |
| 308 the following HTML file: |
| 309 |
| 310 ```html |
| 311 <!doctype html> |
| 312 <!-- custom_html_test.html --> |
| 313 <html> |
| 314 <head> |
| 315 <title>Custom HTML Test</title> |
| 316 <link rel="x-dart-test" href="custom_html_test.dart"> |
| 317 <script src="packages/test/dart.js"></script> |
| 318 </head> |
| 319 <body> |
| 320 // ... |
| 321 </body> |
| 322 </html> |
| 323 ``` |
| 324 |
| 325 ## Configuring Tests |
| 326 |
| 327 ### Skipping Tests |
| 328 |
| 329 If a test, group, or entire suite isn't working yet and you just want it to stop |
| 330 complaining, you can mark it as "skipped". The test or tests won't be run, and, |
| 331 if you supply a reason why, that reason will be printed. In general, skipping |
| 332 tests indicates that they should run but is temporarily not working. If they're |
| 333 is fundamentally incompatible with a platform, [`@TestOn`/`testOn`][TestOn] |
| 334 should be used instead. |
| 335 |
| 336 [TestOn]: #restricting-tests-to-certain-platforms |
| 337 |
| 338 To skip a test suite, put a `@Skip` annotation at the top of the file: |
| 339 |
| 340 ```dart |
| 341 @Skip("currently failing (see issue 1234)") |
| 342 |
| 343 import "package:test/test.dart"; |
| 344 |
| 345 void main() { |
| 346 // ... |
| 347 } |
| 348 ``` |
| 349 |
| 350 The string you pass should describe why the test is skipped. You don't have to |
| 351 include it, but it's a good idea to document why the test isn't running. |
| 352 |
| 353 Groups and individual tests can be skipped by passing the `skip` parameter. This |
| 354 can be either `true` or a String describing why the test is skipped. For example
: |
| 355 |
| 356 ```dart |
| 357 import "package:test/test.dart"; |
| 358 |
| 359 void main() { |
| 360 group("complicated algorithm tests", () { |
| 361 // ... |
| 362 }, skip: "the algorithm isn't quite right"); |
| 363 |
| 364 test("error-checking test", () { |
| 365 // ... |
| 366 }, skip: "TODO: add error-checking."); |
| 367 } |
| 368 ``` |
| 369 |
| 370 ### Timeouts |
| 371 |
| 372 By default, tests will time out after 30 seconds of inactivity. However, this |
| 373 can be configured on a per-test, -group, or -suite basis. To change the timeout |
| 374 for a test suite, put a `@Timeout` annotation at the top of the file: |
| 375 |
| 376 ```dart |
| 377 @Timeout(const Duration(seconds: 45)) |
| 378 |
| 379 import "package:test/test.dart"; |
| 380 |
| 381 void main() { |
| 382 // ... |
| 383 } |
| 384 ``` |
| 385 |
| 386 In addition to setting an absolute timeout, you can set the timeout relative to |
| 387 the default using `@Timeout.factor`. For example, `@Timeout.factor(1.5)` will |
| 388 set the timeout to one and a half times as long as the default—45 seconds. |
| 389 |
| 390 Timeouts can be set for tests and groups using the `timeout` parameter. This |
| 391 parameter takes a `Timeout` object just like the annotation. For example: |
| 392 |
| 393 ```dart |
| 394 import "package:test/test.dart"; |
| 395 |
| 396 void main() { |
| 397 group("slow tests", () { |
| 398 // ... |
| 399 |
| 400 test("even slower test", () { |
| 401 // ... |
| 402 }, timeout: new Timeout.factor(2)) |
| 403 }, timeout: new Timeout(new Duration(minutes: 1))); |
| 404 } |
| 405 ``` |
| 406 |
| 407 Nested timeouts apply in order from outermost to innermost. That means that |
| 408 "even slower test" will take two minutes to time out, since it multiplies the |
| 409 group's timeout by 2. |
| 410 |
| 411 ### Platform-Specific Configuration |
| 412 |
| 413 Sometimes a test may need to be configured differently for different platforms. |
| 414 Windows might run your code slower than other platforms, or your DOM |
| 415 manipulation might not work right on Safari yet. For these cases, you can use |
| 416 the `@OnPlatform` annotation and the `onPlatform` named parameter to `test()` |
| 417 and `group()`. For example: |
| 418 |
| 419 ```dart |
| 420 @OnPlatform(const { |
| 421 // Give Windows some extra wiggle-room before timing out. |
| 422 "windows": const Timeout.factor(2) |
| 423 }) |
| 424 |
| 425 import "package:test/test.dart"; |
| 426 |
| 427 void main() { |
| 428 test("do a thing", () { |
| 429 // ... |
| 430 }, onPlatform: { |
| 431 "safari": new Skip("Safari is currently broken (see #1234)") |
| 432 }); |
| 433 } |
| 434 ``` |
| 435 |
| 436 Both the annotation and the parameter take a map. The map's keys are [platform |
| 437 selectors](#platform-selector-syntax) which describe the platforms for which the |
| 438 specialized configuration applies. Its values are instances of some of the same |
| 439 annotation classes that can be used for a suite: `Skip` and `Timeout`. A value |
| 440 can also be a list of these values. |
| 441 |
| 442 If multiple platforms match, the configuration is applied in order from first to |
| 443 last, just as they would in nested groups. This means that for configuration |
| 444 like duration-based timeouts, the last matching value wins. |
| 445 |
| 446 ## Testing With `barback` |
| 447 |
| 448 Packages using the `barback` transformer system may need to test code that's |
| 449 created or modified using transformers. The test runner handles this using the |
| 450 `--pub-serve` option, which tells it to load the test code from a `pub serve` |
| 451 instance rather than from the filesystem. |
| 452 |
| 453 Before using the `--pub-serve` option, add the `test/pub_serve` transformer to |
| 454 your `pubspec.yaml`. This transformer adds the necessary bootstrapping code that |
| 455 allows the test runner to load your tests properly: |
| 456 |
| 457 ```yaml |
| 458 transformers: |
| 459 - test/pub_serve: |
| 460 $include: test/**_test{.*,}.dart |
| 461 ``` |
| 462 |
| 463 Note that if you're using the test runner along with [`polymer`][polymer], you |
| 464 have to make sure that the `test/pub_serve` transformer comes *after* the |
| 465 `polymer` transformer: |
| 466 |
| 467 [polymer]: https://www.dartlang.org/polymer/ |
| 468 |
| 469 ```yaml |
| 470 transformers: |
| 471 - polymer |
| 472 - test/pub_serve: |
| 473 $include: test/**_test{.*,}.dart |
| 474 ``` |
| 475 |
| 476 Then, start up `pub serve`. Make sure to pay attention to which port it's using |
| 477 to serve your `test/` directory: |
| 478 |
| 479 ```shell |
| 480 $ pub serve |
| 481 Loading source assets... |
| 482 Loading test/pub_serve transformers... |
| 483 Serving my_app web on http://localhost:8080 |
| 484 Serving my_app test on http://localhost:8081 |
| 485 Build completed successfully |
| 486 ``` |
| 487 |
| 488 In this case, the port is `8081`. In another terminal, pass this port to |
| 489 `--pub-serve` and otherwise invoke `pub run test:test` as normal: |
| 490 |
| 491 ```shell |
| 492 $ pub run test:test --pub-serve=8081 -p chrome |
| 493 "pub serve" is compiling test/my_app_test.dart... |
| 494 "pub serve" is compiling test/utils_test.dart... |
| 495 00:00 +42: All tests passed! |
| 496 ``` |
| OLD | NEW |