Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(1278)

Side by Side Diff: benchmark/input.md

Issue 1314153005: Take a first pass at adding a benchmark. (Closed) Base URL: https://github.com/dart-lang/markdown.git@master
Patch Set: Created 5 years, 3 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
OLDNEW
(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 ![Single file being run via pub run"](https://raw.githubusercontent.com/dart-lan g/test/master/image/test1.gif)
86
87 Many tests can be run at a time using `pub run test:test path/to/dir`.
88
89 ![Directory being run via "pub run".](https://raw.githubusercontent.com/dart-lan g/test/master/image/test2.gif)
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 ```
OLDNEW
« benchmark/benchmark.dart ('K') | « benchmark/benchmark.dart ('k') | benchmark/output.html » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698