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
Copy file name to clipboardExpand all lines: docs/en/testing.md
+44-44Lines changed: 44 additions & 44 deletions
Original file line number
Diff line number
Diff line change
@@ -1,15 +1,15 @@
1
-
# Testing
1
+
# Tests
2
2
3
-
The main parts we want to unit test in Vuex are mutations and actions.
3
+
Les parties principales que l'on veut couvrir par des tests unitaires avec Vuex sont les mutations et les actions.
4
4
5
-
### Testing Mutations
5
+
### Tester les mutations
6
6
7
-
Mutations are very straightforward to test, because they are just functions that completely rely on their arguments. One trick is that if you are using ES2015 modules and put your mutations inside your `store.js` file, in addition to the default export, you can also export the mutations as a named export:
7
+
Les mutations sont très simples à tester, puisque ce sont de simples fonctions qui se basent uniquement sur leurs arguments. Une astuce est que si vous utilisez les modules ES2015 et mettez vos mutations dans votre fichier `store.js`, en plus de l'export par défaut, vous pouvez également exporter vos mutations avec un export nommé :
8
8
9
9
```js
10
10
conststate= { ... }
11
11
12
-
//export mutations as a named export
12
+
//exporter les mutations en tant qu'export nommé
13
13
exportconstmutations= { ... }
14
14
15
15
exportdefaultnewVuex.Store({
@@ -18,7 +18,7 @@ export default new Vuex.Store({
18
18
})
19
19
```
20
20
21
-
Example testing a mutation using Mocha + Chai (you can use any framework/assertion libraries you like):
21
+
Exemple de test de mutation utilisant Mocha + Chai (vous pouvez utiliser n'importe quel framework/bibliothèque d'assertion selon vos préférences) :
22
22
23
23
```js
24
24
// mutations.js
@@ -32,26 +32,26 @@ export const mutations = {
32
32
import { expect } from'chai'
33
33
import { mutations } from'./store'
34
34
35
-
//destructure assign mutations
35
+
//assignement des mutations par déstructuration
36
36
const { increment } = mutations
37
37
38
38
describe('mutations', () => {
39
39
it('INCREMENT', () => {
40
-
//mock state
40
+
//état simulé
41
41
conststate= { count:0 }
42
-
//apply mutation
42
+
//appliquer la mutation
43
43
increment(state)
44
-
//assert result
44
+
//tester le résultat
45
45
expect(state.count).to.equal(1)
46
46
})
47
47
})
48
48
```
49
49
50
-
### Testing Actions
50
+
### Tester les actions
51
51
52
-
Actions can be a bit more tricky because they may call out to external APIs. When testing actions, we usually need to do some level of mocking - for example, we can abstract the API calls into a service and mock that service inside our tests. In order to easily mock dependencies, we can use webpack and[inject-loader](https://github.com/plasticine/inject-loader)to bundle our test files.
52
+
Les actions sont un peu plus compliquées car elles peuvent faire appel à des APIs externes. Lorsque l'on teste des actions, on a souvent besoin de faire plusieurs niveaux de simulation. Par exemple, on peut abstraire l'appel API dans un service et simuler ce service dans nos tests. Afin de simuler facilement les dépendances, on peut utiliser webpack et[inject-loader](https://github.com/plasticine/inject-loader)pour regrouper nos fichiers de test.
If your getters have complicated computation, it is worth testing them. Getters are also very straightforward to test as same reason as mutations.
133
+
Si vos accesseurs font des calculs compliqués, il peut être judicieux de les tester. Les accesseurs sont également très simples à tester, pour les mêmes raisons que les mutations.
134
134
135
-
Example testing a getter:
135
+
Exemple de test d'un accesseur :
136
136
137
137
```js
138
138
// getters.js
@@ -152,21 +152,21 @@ import { getters } from './getters'
If your mutations and actions are written properly, the tests should have no direct dependency on Browser APIs after proper mocking. Thus you can simply bundle the tests with webpack and run it directly in Node. Alternatively, you can use`mocha-loader`or Karma + `karma-webpack`to run the tests in real browsers.
180
+
Si vos mutations et actions sont écrites comme il se doit, les tests ne devraient pas avoir de dépendance directe sur les APIs navigateur après une simulation préalable. Cela signifie que vous pouvez simplement regrouper les tests avec webpack et les lancer directement dans Node.js. De façon alternative, vous pouvez utiliser`mocha-loader`ou Karma + `karma-webpack`afin d'effectuer les tests dans des vrais navigateurs.
181
181
182
-
#### Running in Node
182
+
#### Lancer dans Node.js
183
183
184
-
Create the following webpack config (together with proper [`.babelrc`](https://babeljs.io/docs/usage/babelrc/)):
184
+
Créez la configuration webpack suivante (ainsi que le fichier [`.babelrc`](https://babeljs.io/docs/usage/babelrc/) qui correspond) :
185
185
186
186
```js
187
187
// webpack.config.js
@@ -203,20 +203,20 @@ module.exports = {
203
203
}
204
204
```
205
205
206
-
Then:
206
+
Puis :
207
207
208
208
```bash
209
209
webpack
210
210
mocha test-bundle.js
211
211
```
212
212
213
-
#### Running in Browser
213
+
#### Lancer dans un navigateur
214
214
215
-
1.Install`mocha-loader`
216
-
2.Change the`entry`from the webpack config above to`'mocha!babel!./test.js'`.
0 commit comments