You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Set Yadda options
* check for setup* annotation for scenario setup
* use default localisation in blueprint steps.js
* set localisation from configuration for both parsing features and steps
* update dummy app generated files
* update test fixtures
* bump version
* replaces #42
For the older APIs use v0.3.x and have a look at our [Legacy Guide](docs/legacy.md).
@@ -40,7 +40,7 @@ You may specify the version of yadda by changing it in package.json and running
40
40
41
41
## Upgrading
42
42
43
-
To upgrade to the latest version of this addon from a previous release < 0.4.0, including refactoring your existing
43
+
To upgrade to the latest version of this addon from a previous release < 0.4.0, including refactoring your existing
44
44
tests to Ember's new testing APIs, follow these steps:
45
45
46
46
- Install the latest version of ember-cli-yadda.
@@ -49,11 +49,11 @@ tests to Ember's new testing APIs, follow these steps:
49
49
- Refactor your step files to use the new testing APIs:
50
50
- for application tests, skip using Ember's global test helpers and use those provided by [@ember/test-helpers](https://github.com/emberjs/ember-test-helpers).
51
51
- use `async`/`await` for all asynchronous operations, including `andThen()`
52
-
-[ember-test-helpers-codemod](https://github.com/simonihmig/ember-test-helpers-codemod) will be able to do most of
52
+
-[ember-test-helpers-codemod](https://github.com/simonihmig/ember-test-helpers-codemod) will be able to do most of
53
53
these changes automatically
54
54
- For further details have a look at the [Migration Guide for QUnit](https://github.com/emberjs/ember-qunit/blob/master/docs/migration.md)
55
55
or the [Migration Guide for Mocha](https://github.com/emberjs/ember-mocha/blob/master/docs/migration.md#upgrading-to-the-new-testing-apis)
56
-
-*Optional*: customize `tests/helpers/yadda-annotations.js` with any additional setup logic that is needed, see
56
+
-*Optional*: customize `tests/helpers/yadda-annotations.js` with any additional setup logic that is needed, see
57
57
[here](#customization)
58
58
59
59
## Usage
@@ -89,8 +89,8 @@ This will generate the following files in your project directory:
89
89
90
90
#### Integration or unit tests
91
91
92
-
To create an integration or unit test, you can use `ember g feature [feature title] --type=integration` for an
93
-
integration test, or `--type=unit` for a unit test. This generates a feature and step definition file where you can
92
+
To create an integration or unit test, you can use `ember g feature [feature title] --type=integration` for an
93
+
integration test, or `--type=unit` for a unit test. This generates a feature and step definition file where you can
94
94
write your tests.
95
95
96
96
For example:
@@ -121,26 +121,26 @@ Feature: bananas rot
121
121
Then the banana rots
122
122
```
123
123
124
-
The `@setupApplicationTest` annotation will setup all scenarios of this feature as application tests, using the
124
+
The `@setupApplicationTest` annotation will setup all scenarios of this feature as application tests, using the
125
125
`setupApplicationTest()` function provided by either `ember-qunit` or `ember-mocha`. See the [Annotations](#annotations)
126
126
section below for more information on how to setup your tests.
127
127
128
-
Because we probably have more features about bananas, we add the `Given I have bananas` to the global steps file:
128
+
Because we probably have more features about bananas, we add the `Given I have bananas` to the global steps file:
129
129
`/tests/acceptance/steps.js`
130
130
131
131
```js
132
132
importyaddafrom'../../helpers/yadda';
133
-
import { visit } from'@ember/test-helpers';
133
+
import { visit } from'@ember/test-helpers';
134
134
135
135
exportdefaultfunction(assert) {
136
-
returnyadda.localisation.English.library()
136
+
returnyadda.localisation.default.library()
137
137
.given("I have bananas", asyncfunction() {
138
138
awaitvisit("/bananas");
139
139
});
140
140
}
141
141
```
142
142
143
-
*Notice that the preferable way to handle asynchronous steps like the one above is to use `async`/ `await`. But you can
143
+
*Notice that the preferable way to handle asynchronous steps like the one above is to use `async`/ `await`. But you can
144
144
also explicitly return a promise or use a `next()`[callback](https://acuminous.gitbooks.io/yadda-user-guide/en/usage/step-libraries.html).*
145
145
146
146
The fact that "it's next to apples" is probably unique to this Feature so we'll add it to the feature specific step definitions in `/tests/acceptance/steps/bananas-rot-feature-steps.js`. That will look like this:
ember-cli-yadda passes the original scope down to each step definition. This means that you have access to the same
176
-
context (like `this.element` or `this.owner`) and helpers from `@ember/test-helpers` (like `click()`), as you did when
175
+
ember-cli-yadda passes the original scope down to each step definition. This means that you have access to the same
176
+
context (like `this.element` or `this.owner`) and helpers from `@ember/test-helpers` (like `click()`), as you did when
177
177
writing a normal test in QUnit/Mocha.
178
178
179
179
##### Sharing variables between steps
@@ -215,23 +215,23 @@ You already saw the use of the `@setupApplicationTest` annotation in the example
215
215
Yadda's [support for annotations](https://acuminous.gitbooks.io/yadda-user-guide/en/feature-specs/annotations.html`) can
216
216
be used to customize the way tests are run.
217
217
218
-
The implementation for the way certain annotations affect your tests lives in the `tests/yadda-annotations.js` file.
218
+
The implementation for the way certain annotations affect your tests lives in the `tests/yadda-annotations.js` file.
219
219
The addon installs this file with a default implementation as described below, but you can freely customize it at your
220
220
will.
221
221
222
222
#### Skipping tests
223
223
224
-
You can skip tests by adding the `@ignore` annotation above the Scenario or Feature.
224
+
You can skip tests by adding the `@ignore` annotation above the Scenario or Feature.
225
225
226
226
#### Test suites
227
227
228
-
You can set `ENV.annotations` to an array of annotations (either statically or e.g. by assigning them from an
228
+
You can set `ENV.annotations` to an array of annotations (either statically or e.g. by assigning them from an
229
229
environment variable like `process.env.ANNOTATIONS`). This will then run only those Features or Scenarios that have one
230
230
of these annotations assigned.
231
231
232
232
#### Setup tests
233
233
234
-
For each of the setup functions already known from `ember-qunit` or `ember-mocha`, there exists a corresponding
234
+
For each of the setup functions already known from `ember-qunit` or `ember-mocha`, there exists a corresponding
235
235
annotation to setup your Feature/Scenario accordingly:
236
236
237
237
-`@setupTest` for (unit) tests requiring the DI container of Ember to be set up
@@ -240,20 +240,20 @@ annotation to setup your Feature/Scenario accordingly:
240
240
241
241
#### Customization
242
242
243
-
You can customize how annotations are handled in your app's `tests/yadda-annotations.js` file, e.g. to add support for
243
+
You can customize how annotations are handled in your app's `tests/yadda-annotations.js` file, e.g. to add support for
244
244
additional annotations, or extend the existing ones. This module has to export these hooks, that are called by this
245
245
addon's test runner:
246
246
247
247
-`runFeature`: called for each feature. If you return a function, this will be called to run the feature, instead of
248
248
the default implementation.
249
249
-`runScenario`: similar to `runFeature`, but called for each scenario.
250
-
-`setupFeature`: called for each feature to setup the test environment. You can call QUnit's or Mocha's `beforeEach`
250
+
-`setupFeature`: called for each feature to setup the test environment. You can call QUnit's or Mocha's `beforeEach`
251
251
and `afterEach` functions here to add custom setup/teardown work.
252
252
-`setupScenario`: similar to `setupFeature`, but called for each scenario.
253
253
254
254
Have a look at the existing implementation and the comments present in your `tests/yadda-annotations.js` file!
255
255
256
-
Here is an example to extend the defaul implementation of the `@setupApplicationTest` annotation to also call the
256
+
Here is an example to extend the defaul implementation of the `@setupApplicationTest` annotation to also call the
257
257
`setupMirage()` function provided by `ember-cli-mirage` to setup the Mirage server:
258
258
259
259
```js
@@ -272,6 +272,25 @@ function setupYaddaTest(annotations) {
272
272
}
273
273
```
274
274
275
+
### Yadda Configuration
276
+
If you need to set Yadda configuration, add the following to `ember-cli-build.js`:
277
+
278
+
```javascript
279
+
module.exports=function(defaults) {
280
+
let app =newEmberApp(defaults, {
281
+
282
+
'ember-cli-yadda': {
283
+
yaddaOptions: { // passed through to yadda parseFeature()
284
+
language:'Polish', // converted to Yadda.localisation.Polish
285
+
leftPlaceholderChar:'<',
286
+
rightPlaceholderChar:'>'
287
+
}
288
+
289
+
}
290
+
});
291
+
```
292
+
See [yadda FeatureParser]([https://github.com/acuminous/yadda/blob/master/lib/parsers/FeatureParser.js#L8]) for yadda options.
293
+
275
294
## Inner workings
276
295
277
296
This ember addon registers a preprocessor that parses `.feature` / `.spec` / `.specification` files using [yadda](https://github.com/acuminous/yadda) and generates a `-test.js` file in the apropriate test folder. It also adds a little loader helper ``/tests/helpers/yadda.js`` because yadda does not define an amd module.
0 commit comments