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
For UI components, we don't recommend aiming for complete line-based coverage, because it leads to too much focus on the internal implementation details of the components and could result in brittle tests.
5
+
Pour les composants graphiques (UI), nous ne recommandons pas une couverture complète. En effet, cela mène à trop d'attention sur les détails de l'implémentation interne des composants et pourrait produire des tests instables.
6
6
7
-
Instead, we recommend writing tests that assert your component's public interface, and treat its internals as a black box. A single test case would assert that some input (user interaction or change of props) provided to the component results in the expected output (render result or emitted custom events).
7
+
A contrario, nous recommandons d'écrire des tests qui vérifient le bon fonctionnement de l'interface public de vos composants et ainsi traiter le cœur de ceux-ci telle une boîte noire. Un simple test pourrait vérifier qu'une entrée utilisateur (due à une interaction ou un changement de props) passée au composant nous donnerait le résultat attendu (cela peut être un nouveau rendu ou l'envoi d'un évènement).
8
8
9
-
For example, for the `Counter` component which increments a display counter by 1 each time a button is clicked, its test case would simulate the click and assert that the rendered output has increased by 1. The test doesn't care about how the Counter increments the value, it only cares about the input and the output.
9
+
Par exemple, pour le composant `Counter`, qui incrémente un compteur visible de 1 à chaque fois qu'un bouton est cliqué, le scénario de test devrait simuler le clic puis s'assurer que le rendu visuel a bien été incrémenté d'un aussi. Le test se fiche de savoir comment le compteur a incrémenté la valeur, il s'occupe seulement de l'entrée et de la sortie (du résultat).
10
10
11
-
The benefit of this approach is that as long as your component's public interface remains the same, your tests will pass no matter how the component's internal implementation changes over time.
11
+
Le bénéfice de cette approche est que tant que l'interface public de votre composant reste la même, vos tests passeront et ce peu importe le comportement interne de votre composant, qui pourrait changer avec le temps.
12
12
13
-
This topic is discussed with more details in a [great presentation by Matt O'Connell](http://slides.com/mattoconnell/deck#/).
13
+
Ce sujet est discuté plus en détails dans une [très bonne présentation de Matt O'Connell](http://slides.com/mattoconnell/deck#/).
14
14
15
-
## Shallow Rendering
15
+
## Rendu superficiel
16
16
17
-
In unit tests, we typically want to focus on the component being tested as an isolated unit and avoid indirectly asserting the behavior of its child components.
17
+
Dans des tests unitaires, on souhaite s'intéresser au composant qui est en train d'être testé comme une unité isolée et ainsi éviter de s'assurer du bon comportement des composants enfants.
18
18
19
-
In addition, for components that contain many child components, the entire rendered tree can get really big. Repeatedly rendering all child components could slow down our tests.
19
+
De plus, pour les composants qui contiennent beaucoup de composants enfant, l'intégralité de l'arbre de rendu peut être énorme. Répétitivement rendre tous les composants pourrait réduire la vitesse de nos tests.
20
20
21
-
`vue-test-utils`allows you to mount a component without rendering its child components (by stubbing them) with the `shallow`method:
21
+
`vue-test-utils`vous permets de monter un composant sans avoir à rendre ses composants enfants (en les ignorants) avec la méthode `shallow` :
22
22
23
23
```js
24
24
import { shallow } from'vue-test-utils'
25
25
26
-
constwrapper=shallow(Component) //returns a Wrapper containing a mounted Component instance
27
-
wrapper.vm//the mounted Vue instance
26
+
constwrapper=shallow(Component) //retourne un wrapper contenant une instance de composant montée
27
+
wrapper.vm//l'instance de Vue montée
28
28
```
29
29
30
-
## Asserting Emitted Events
30
+
## Assertion d'évènements émis
31
31
32
-
Each mounted wrapper automatically records all events emitted by the underlying Vue instance. You can retrieve the recorded events using the `wrapper.emitted()`method:
32
+
Chaque wrapper monté va automatiquement enregistrer les évènements émis par l'instance de Vue en question. Vous pouvez récupérer ces évènements en utilisant la méthode `wrapper.emitted()` :
33
33
34
34
```js
35
35
wrapper.vm.$emit('foo')
36
36
wrapper.vm.$emit('foo', 123)
37
37
38
38
/*
39
-
wrapper.emitted() returns the following object:
39
+
`wrapper.emitted()` retourne l'objet suivant :
40
40
{
41
41
foo: [[], [123]]
42
42
}
43
43
*/
44
44
```
45
45
46
-
You can then make assertions based on these data:
47
-
46
+
Vous pouvez ensuite réaliser des assertions sur ces données :
48
47
```js
49
48
import { expect } from'chai'
50
49
51
-
//assert event has been emitted
50
+
//asserte que l'évènement est bien émit
52
51
expect(wrapper.emitted().foo).toBeTruthy()
53
52
54
-
//assert event count
53
+
//asserte la taille du compteur d'évènement
55
54
expect(wrapper.emitted().foo.length).toBe(2)
56
55
57
-
//assert event payload
56
+
//asserte le contenu lié à l'évènement
58
57
expect(wrapper.emitted().foo[1]).toEqual([123])
59
58
```
60
59
61
-
You can also get an Array of the events in their emit order by calling [wrapper.emittedByOrder()](../api/wrapper/emittedByOrder.md).
60
+
Vous pouvez aussi récupérer un tableau des évènements dans l'ordre d'émition en appelant [`wrapper.emittedByOrder()`](../api/wrapper/emittedByOrder.md).
62
61
63
-
## Manipulating Component State
62
+
## Manipuler l'état d'un composant
64
63
65
-
You can directly manipulate the state of the component using the`setData`or`setProps`method on the wrapper:
64
+
Vous pouvez directement manipuler l'état d'un composant en utilisant la méthode`setData`ou`setProps`sur le wrapper:
66
65
67
66
```js
68
67
wrapper.setData({ count:10 })
69
68
70
69
wrapper.setProps({ foo:'bar' })
71
70
```
72
71
73
-
## Mocking Props
72
+
## Simuler des props
74
73
75
-
You can pass props to the component using Vue's built-in `propsData`option:
74
+
Vous pouvez passer des props au composant en utilisant l'option `propsData`de Vue :
76
75
77
76
```js
78
77
import { mount } from'vue-test-utils'
79
78
80
79
mount(Component, {
81
80
propsData: {
82
-
aProp:'some value'
81
+
aProp:'une valeur'
83
82
}
84
83
})
85
84
```
86
85
87
-
You can also update the props of an already-mounted component with the `wrapper.setProps({})` method.
86
+
Vous pouvez aussi mettre à jour les props d'un composant déjà monté avec la méthode `wrapper.setProps({})`.
88
87
89
-
*For a full list of options, please see the [mount options section](../api/options.md)of the docs.*
88
+
*Pour une liste complète des options, veuillez regarder [la section sur les options de montage](../api/options.md)de la documentation.*
90
89
91
-
## Applying Global Plugins and Mixins
90
+
## Appliquer des plugins globaux et des mixins
92
91
93
-
Some of the components may rely on features injected by a global plugin or mixin, for example`vuex`and`vue-router`.
92
+
Des composants pourraient se fier à des fonctionnalités injectées par un plugin global ou un mixin, par exemple`vuex`ou`vue-router`.
94
93
95
-
If you are writing tests for components in a specific app, you can setup the same global plugins and mixins once in the entry of your tests. But in some cases, for example testing a generic component suite that may get shared across different apps, it's better to test your components in a more isolated setup, without polluting the global `Vue` constructor. We can use the [createLocalVue](../api/createLocalVue.md)method to achieve that:
94
+
Si vous écrivez des tests pour des composants dans une application spécifique, vous pouvez mettre en place les mêmes plugins globaux et mixins en une seule fois dans vos tests. Dans certains cas, comme tester un composant générique utilisé par des applications différentes, il est favorable de tester ces composants dans une installation plus isolée, sans avoir à polluer le constructeur global `Vue`. On peut utiliser la méthode [`createLocalVue`](../api/createLocalVue.md)pour faire cela :
96
95
97
96
```js
98
97
importcreateLocalVuefrom'vue-test-utils'
99
98
100
-
//create an extended Vue constructor
99
+
//créer un constructeur local de Vue
101
100
constlocalVue=createLocalVue()
102
101
103
-
//install plugins as normal
102
+
//installer des plugins comme d'habitude
104
103
localVue.use(MyPlugin)
105
104
106
-
//pass the localVue to the mount options
105
+
//passe la `localVue` aux options de montage
107
106
mount(Component, {
108
107
localVue
109
108
})
110
109
```
111
110
112
-
## Mocking Injections
111
+
## Simuler des injections
113
112
114
-
Another strategy for injected properties is simply mocking them. You can do that with the`mocks`option:
113
+
Une stratégie alternative pour injecter des propriétés est de simplement les simuler. Vous pouvez faire cela avec l'option`mocks` :
115
114
116
115
```js
117
116
import { mount } from'vue-test-utils'
@@ -120,16 +119,16 @@ const $route = {
120
119
path:'/',
121
120
hash:'',
122
121
params: { id:'123' },
123
-
query: { q:'hello' }
122
+
query: { q:'bonjour' }
124
123
}
125
124
126
125
mount(Component, {
127
126
mocks: {
128
-
$route //adds the mocked $route object to the Vue instance before mounting component
127
+
$route //ajoute l'objet route simulé à l'instance de Vue avant de monter le composant
129
128
}
130
129
})
131
130
```
132
131
133
-
## Dealing with Routing
132
+
## Gérer le routage
134
133
135
-
Since routing by definition has to do with the overall structure of the application and involves multiple components, it is best tested via integration or end-to-end tests. For individual components that rely on `vue-router` features, you can mock them using the techniques mentioned above.
134
+
Depuis que le routage, par définition, porte sur la structure générale de l'application et implique plusieurs composants. Il est mieux testé via des tests d'intégration ou point à point (end-to-end). Pour des composants individuels qui se fie aux fonctionnalités de `vue-router`, vous pouvez les simuler en utilisant les techniques mentionnées plus haut.
0 commit comments