Skip to content

Commit 1f4b52b

Browse files
committed
Update testing.md
Signed-off-by: Bruno Lesieur <[email protected]>
1 parent 4dc4b9d commit 1f4b52b

File tree

1 file changed

+24
-24
lines changed

1 file changed

+24
-24
lines changed

docs/en/testing.md

Lines changed: 24 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Tests
22

3-
Les parties principales que l'on veut couvrir par des tests unitaires en Vuex sont les mutations et les actions.
3+
Les parties principales que l'on veut couvrir par des tests unitaires avec Vuex sont les mutations et les actions.
44

55
### Tester les mutations
66

@@ -9,7 +9,7 @@ Les mutations sont très simples à tester, puisque ce sont de simples fonctions
99
``` js
1010
const state = { ... }
1111

12-
// export mutations as a named export
12+
// exporter les mutations en tant qu'export nommé
1313
export const mutations = { ... }
1414

1515
export default new Vuex.Store({
@@ -32,24 +32,24 @@ export const mutations = {
3232
import { expect } from 'chai'
3333
import { mutations } from './store'
3434

35-
// destructure assign mutations
35+
// assginement des mutations par destructuration
3636
const { increment } = mutations
3737

3838
describe('mutations', () => {
3939
it('INCREMENT', () => {
40-
// mock state
40+
// jeu d'état de test
4141
const state = { count: 0 }
42-
// apply mutation
42+
// appliquer la mutation
4343
increment(state)
44-
// assert result
44+
// tester le résultat
4545
expect(state.count).to.equal(1)
4646
})
4747
})
4848
```
4949

5050
### Tester les actions
5151

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 du mocking &mdash; par exemple, on peut abstraire l'appel API dans un service et mocker ce service dans nos tests. Afin de mocker facilement les dépendances, on peut utiliser webpack et [inject-loader](https://github.com/plasticine/inject-loader) pour regrouper nos fichiers de test.
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 des jeux de test dédiés. 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.
5353

5454
Exemple de test d'une action asynchrone :
5555

@@ -68,28 +68,28 @@ export const getAllProducts = ({ commit }) => {
6868
``` js
6969
// actions.spec.js
7070

71-
// use require syntax for inline loaders.
72-
// with inject-loader, this returns a module factory
73-
// that allows us to inject mocked dependencies.
71+
// étulisation de la syntaxe `require` pour les loaders.
72+
// avec inject-loader, cela retourne un module le fabrique
73+
// cela nous permet d'injecter les dépendances simulées.
7474
import { expect } from 'chai'
7575
const actionsInjector = require('inject!./actions')
7676

77-
// create the module with our mocks
77+
// créer un module avec nos simulations
7878
const actions = actionsInjector({
7979
'../api/shop': {
8080
getProducts (cb) {
8181
setTimeout(() => {
82-
cb([ /* mocked response */ ])
82+
cb([ /* réponse simulée */ ])
8383
}, 100)
8484
}
8585
}
8686
})
8787

88-
// helper for testing action with expected mutations
88+
// fonction utilitaire pour tester des actions avec les mutations attendues
8989
const testAction = (action, args, state, expectedMutations, done) => {
9090
let count = 0
9191

92-
// mock commit
92+
// acter une simulation
9393
const commit = (type, payload) => {
9494
const mutation = expectedMutations[count]
9595

@@ -108,7 +108,7 @@ const testAction = (action, args, state, expectedMutations, done) => {
108108
}
109109
}
110110

111-
// call the action with mocked store and arguments
111+
// appler l'action avec le store simulé et les arguments
112112
action({ commit, state }, ...args)
113113

114114
// check if no mutations should have been dispatched
@@ -128,11 +128,11 @@ describe('actions', () => {
128128
})
129129
```
130130

131-
### Tester les getters
131+
### Tester les accesseurs
132132

133-
Si vos getters font des calculs compliqués, il peut être judicieux de les tester. Les getters sont également très simples à tester, pour les mêmes raisons que les 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.
134134

135-
Exemple de test d'un getter :
135+
Exemple de test d'un accesseur :
136136

137137
``` js
138138
// getters.js
@@ -152,21 +152,21 @@ import { getters } from './getters'
152152

153153
describe('getters', () => {
154154
it('filteredProducts', () => {
155-
// mock state
155+
// état simulé
156156
const state = {
157157
products: [
158158
{ id: 1, title: 'Apple', category: 'fruit' },
159159
{ id: 2, title: 'Orange', category: 'fruit' },
160160
{ id: 3, title: 'Carrot', category: 'vegetable' }
161161
]
162162
}
163-
// mock getter
163+
// accesseur simulé
164164
const filterCategory = 'fruit'
165165

166-
// get the result from the getter
166+
// obterir le résultat depuis l'accesseur
167167
const result = getters.filteredProducts(state, { filterCategory })
168168

169-
// assert the result
169+
// tester le résultat
170170
expect(result).to.deep.equal([
171171
{ id: 1, title: 'Apple', category: 'fruit' },
172172
{ id: 2, title: 'Orange', category: 'fruit' }
@@ -177,9 +177,9 @@ describe('getters', () => {
177177

178178
### Lancer les tests
179179

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 un mocking préalable. Cela signifie que vous pouvez simplement regrouper les tests avec webpack et les lancer directement dans Node. De façon alternative, vous pouvez utiliser `mocha-loader` ou Karma + `karma-webpack` afin d'effectuer les tests dans des vrais navigateurs.
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 un 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.
181181

182-
#### Lancer dans Node
182+
#### Lancer dans Node.js
183183

184184
Créez la configuration webpack suivante (ainsi que le fichier [`.babelrc`](https://babeljs.io/docs/usage/babelrc/) qui correspond) :
185185

0 commit comments

Comments
 (0)