| OLD | NEW |
| 1 Each package may include a configuration file that applies to the package as a | 1 Each package may include a configuration file that applies to the package as a |
| 2 whole. This file can be used to provide custom defaults for various options, to | 2 whole. This file can be used to provide custom defaults for various options, to |
| 3 define configuration for multiple files, and more. | 3 define configuration for multiple files, and more. |
| 4 | 4 |
| 5 The file is named `dart_test.yaml` and lives at the root of the package, next to | 5 The file is named `dart_test.yaml` and lives at the root of the package, next to |
| 6 the package's pubspec. Like the pubspec, it's a [YAML][] file. Here's an | 6 the package's pubspec. Like the pubspec, it's a [YAML][] file. Here's an |
| 7 example: | 7 example: |
| 8 | 8 |
| 9 [YAML]: http://yaml.org/ | 9 [YAML]: http://yaml.org/ |
| 10 | 10 |
| (...skipping 164 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
| 175 "expanded", or "json" (although why anyone would want to default to JSON is | 175 "expanded", or "json" (although why anyone would want to default to JSON is |
| 176 beyond me). It defaults to "expanded" on Windows and "compact" everywhere else. | 176 beyond me). It defaults to "expanded" on Windows and "compact" everywhere else. |
| 177 | 177 |
| 178 ```yaml | 178 ```yaml |
| 179 reporter: expanded | 179 reporter: expanded |
| 180 ``` | 180 ``` |
| 181 | 181 |
| 182 ## Configuring Tags | 182 ## Configuring Tags |
| 183 | 183 |
| 184 The `tag` field can be used to apply [test configuration](#test-configuration) | 184 The `tag` field can be used to apply [test configuration](#test-configuration) |
| 185 to all tests [with a given tag][tagging tests]. It takes a map from tag names to | 185 to all tests [with a given tag][tagging tests] or set of tags. It takes a map |
| 186 configuration maps. These configuration maps are just like the top level of the | 186 from tag selectors to configuration maps. These configuration maps are just like |
| 187 configuration file, except that they may not contain | 187 the top level of the configuration file, except that they may not contain |
| 188 [runner configuration](#runner-configuration). | 188 [runner configuration](#runner-configuration). |
| 189 | 189 |
| 190 [tagging tests]: https://github.com/dart-lang/test/blob/master/README.md#tagging
-tests | 190 [tagging tests]: https://github.com/dart-lang/test/blob/master/README.md#tagging
-tests |
| 191 | 191 |
| 192 ```yaml | 192 ```yaml |
| 193 tags: | 193 tags: |
| 194 # Integration tests need more time to run. | 194 # Integration tests need more time to run. |
| 195 integration: | 195 integration: |
| 196 timeout: 1m | 196 timeout: 1m |
| 197 ``` | 197 ``` |
| 198 | 198 |
| 199 Tags may also have no configuration associated with them. The test runner prints | 199 Tags may also have no configuration associated with them. The test runner prints |
| 200 a warning whenever it encounters a tag it doesn't recognize, and this the best | 200 a warning whenever it encounters a tag it doesn't recognize, and this the best |
| 201 way to tell it that a tag exists. | 201 way to tell it that a tag exists. |
| 202 | 202 |
| 203 ```yaml | 203 ```yaml |
| 204 # We occasionally want to use --tags or --exclude-tags on these tags. | 204 # We occasionally want to use --tags or --exclude-tags on these tags. |
| 205 tags: | 205 tags: |
| 206 # A test that spawns a browser. | 206 # A test that spawns a browser. |
| 207 browser: | 207 browser: |
| 208 | 208 |
| 209 # A test that needs Ruby installed. | 209 # A test that needs Ruby installed. |
| 210 ruby: | 210 ruby: |
| 211 ``` | 211 ``` |
| 212 | 212 |
| 213 You can also use [boolean selector syntax][] to define configuration that |
| 214 involves multiple tags. For example: |
| 215 |
| 216 [boolean selector syntax]: https://github.com/dart-lang/boolean_selector/blob/ma
ster/README.md |
| 217 |
| 218 ```yaml |
| 219 tags: |
| 220 # Tests that invoke sub-processes tend to be a little slower. |
| 221 ruby || python: |
| 222 timeout: 1.5x |
| 223 ``` |
| 224 |
| 213 Tag configuration is applied at whatever level the tag appears—so if a group is | 225 Tag configuration is applied at whatever level the tag appears—so if a group is |
| 214 tagged as `integration`, its timeout will take precedence over the suite's | 226 tagged as `integration`, its timeout will take precedence over the suite's |
| 215 timeout but not any tests'. If the group itself had a timeout declared, the | 227 timeout but not any tests'. If the group itself had a timeout declared, the |
| 216 group's explicit timeout would take precedence over the tag. | 228 group's explicit timeout would take precedence over the tag. |
| 217 | 229 |
| 218 If multiple tags appear at the same level, and they have conflicting | 230 If multiple tags appear at the same level, and they have conflicting |
| 219 configurations, the test runner *does not guarantee* what order they'll be | 231 configurations, the test runner *does not guarantee* what order they'll be |
| 220 resolved in. In practice, conflicting configuration is pretty unlikely and it's | 232 resolved in. In practice, conflicting configuration is pretty unlikely and it's |
| 221 easy to just explicitly specify what you want on the test itself. | 233 easy to just explicitly specify what you want on the test itself. |
| 222 | 234 |
| (...skipping 11 matching lines...) Expand all Loading... |
| 234 browser: | 246 browser: |
| 235 timeout: 2x | 247 timeout: 2x |
| 236 | 248 |
| 237 # Tests that spawn specific browsers. These automatically get the browser tag | 249 # Tests that spawn specific browsers. These automatically get the browser tag |
| 238 # as well. | 250 # as well. |
| 239 chrome: {add_tags: [browser]} | 251 chrome: {add_tags: [browser]} |
| 240 firefox: {add_tags: [browser]} | 252 firefox: {add_tags: [browser]} |
| 241 safari: {add_tags: [browser]} | 253 safari: {add_tags: [browser]} |
| 242 ie: {add_tags: [browser]} | 254 ie: {add_tags: [browser]} |
| 243 ``` | 255 ``` |
| OLD | NEW |