Barre latérale
' },
footer: 'Pied de page
',
- }
- })
+ },
+ });
expect(wrapper.html()).toContain('Haut de page
');
expect(wrapper.html()).toContain('Contenu principal
');
@@ -139,7 +139,7 @@ test('affiche la page entière', () => {
## Slots à portée limitée (Scoped Slots)
-[Les slots à portée limitée](https://v3.vuejs.org/guide/component-slots.html#scoped-slots) et les `bindings` sont aussi supportés par VTU.
+[Les slots à portée limitée](https://v3.vuejs.org/guide/component-slots.html#scoped-slots) et les liaisons de données (`bindings`) sont aussi supportés par VTU.
```js
const ComponentWithSlots = {
@@ -185,7 +185,7 @@ test('slot à portée limitée', () => {
## Conclusion
-- Utilisez l'option de `mount()` : `slots` pour tester que les composants utilisant `{{ text }}
',
+ setup() {
+ const text = refonServerPrefetch
');
+});
+```
diff --git a/docs/fr/guide/advanced/stubs-shallow-mount.md b/docs/fr/guide/advanced/stubs-shallow-mount.md
index 77e5cfabd..dfc202c74 100644
--- a/docs/fr/guide/advanced/stubs-shallow-mount.md
+++ b/docs/fr/guide/advanced/stubs-shallow-mount.md
@@ -2,7 +2,7 @@
Vue Test Utils offre certaines fonctionnalités avancées pour substituer (`stubbing`) les composants et les directives. La substitution consiste à remplacer l'implémentation existante d'un composant ou d'une directive personnalisé par une version fictive qui ne fait rien du tout, ce qui peut simplifier un test complexe. Voyons un exemple.
-## Substituer un Seul Composant Enfant
+## Substituer un seul composant enfant
Un exemple courant est lorsque vous souhaitez tester un comportement dans un composant qui apparaît très haut dans la hiérarchie des composants.
@@ -36,7 +36,7 @@ const App = {
};
```
-Nous ne voulons pas effectuer l'appel API dans ce test en particulier, nous voulons simplement vérifier que le message est affiché. Dans ce cas, nous pourrions utiliser les `stubs`, qui apparaissent dans l'option de `mount` : `global`.
+Nous ne voulons pas effectuer l'appel API dans ce test en particulier, nous désirons simplement vérifier que le message est affiché. Dans ce cas, nous pourrions utiliser les `stubs`, qui apparaissent dans l'option de `mount` : `global`.
```js
test('substitue le composant avec un template personnalisé', () => {
@@ -57,9 +57,9 @@ test('substitue le composant avec un template personnalisé', () => {
});
```
-Remarquez comment le template affiche `` à la place de ``. Vous pourriez faire quelque chose comme ceci :
+Imaginez que chacun des `` fasse quelque chose de compliqué, et que vous soyez seulement intéressé par le test de rendu du bon message de ``. Vous pourriez faire quelque chose comme suit :
```js
const wrapper = mount(ComplexComponent, {
@@ -117,7 +117,7 @@ const wrapper = mount(ComplexComponent, {
});
```
-Mais c'est beaucoup de code répétitif. VTU a une option `mount` : `shallow` qui substituera automatiquement tous les composants enfants :
+Mais c'est beaucoup de code répétitif. VTU a une option `mount` : `shallow` qui substituera automatiquement tous les composants enfants :
```js {3}
test('substitue tous les composants enfants', () => {
@@ -139,13 +139,13 @@ test('substitue tous les composants enfants', () => {
Si vous avez utilisé VTU V1, cela vous rappelle sûrement `shallowMount`. Cette méthode est également toujours disponible, c'est la même chose que d'écrire `shallow: true`.
:::
-## Substituer tous les Composants Enfants avec des Exceptions
+## Substituer tous les composants enfants avec des exceptions
-Parfois, vous voulez remplacer *tous* les composants personnalisés, sauf un en particulier. Voyons un exemple :
+Parfois, vous voulez remplacer *tous* les composants personnalisés, sauf un en particulier. Voyons un exemple :
```js
const ComplexA = {
- template: 'Salutation d\'un composant réel !
'
+ template: 'Salutation d\'un composant réel !
',
};
const ComplexComponent = {
@@ -159,7 +159,7 @@ const ComplexComponent = {
};
```
-En utilisant l'option de `mount` : `shallow`, nous substituons automatiquement tous les composants enfants. Si nous voulons explicitement empêcher la substitution d'un composant spécifique, nous pouvons fournir son nom dans `stubs` avec une valeur définie sur `false`.
+En utilisant l'option de `mount` : `shallow`, nous substituons automatiquement tous les composants enfants. Si nous voulons explicitement empêcher la substitution d'un composant spécifique, nous pouvons fournir son nom dans `stubs` avec une valeur définie sur `false`.
```js {3}
test('l\'option shallow permet de subsituter tous les composants enfants sauf ceux dans stubs', () => {
@@ -182,7 +182,7 @@ test('l\'option shallow permet de subsituter tous les composants enfants sauf ce
## Substituer un Composant Asynchrone
-Si vous voulez substituer un composant asynchrone, il existe deux comportements à prendre en compte. Par exemple, vous pourriez avoir des composants de ce genre :
+Si vous voulez substituer un composant asynchrone, il existe deux comportements à prendre en compte. Par exemple, vous pourriez avoir des composants de ce genre :
```js
// AsyncComponent.js
@@ -222,7 +222,7 @@ Le second comportement consiste à utiliser le nom du composant asynchrone. Dans
Maintenant, il est nécessaire d'utiliser `async/await`, car le composant asynchrone doit être résolu et peut alors être remplacé par le nom défini dans le composant asynchrone.
-**Assurez-vous de définir un nom dans votre composant asynchrone !**
+**Assurez-vous de définir un nom dans votre composant asynchrone !**
```js
test('substitue le composant asynchrone avec résolution', async () => {
@@ -242,9 +242,9 @@ test('substitue le composant asynchrone avec résolution', async () => {
## Substituer une directive
-Parfois, les directives effectuent des opérations assez complexes, comme réaliser beaucoup de manipulation de DOM ce qui peut entraîner des erreurs dans vos tests (en raison de JSDOM ne ressemblant pas au comportement entier du DOM). Un exemple courant sont les directives de tooltip de différentes bibliothèques, qui dépendent généralement fortement de la mesure de la position/taille des nœuds DOM.
+Parfois, les directives effectuent des opérations assez complexes, comme réaliser beaucoup de manipulations de DOM ce qui peut entraîner des erreurs dans vos tests (en raison du JsDOM ne ressemblant pas totalement au DOM). Un exemple courant sont les directives de tooltip de différentes bibliothèques, qui dépendent généralement fortement de la mesure de la position/taille des nœuds DOM.
-Dans cet exemple, nous avons un autre `` qui rend un message dans une infobulle.
+Dans cet exemple, nous avons un autre `` qui affiche un message dans une infobulle.
```js
// directive tooltip déclarée quelque part nommée `Tooltip`
@@ -257,7 +257,7 @@ const App = {
};
```
-Nous ne voulons pas que le code de la directive `Tooltip` soit exécuté dans ce test, nous voulons simplement vérifier que le message est affiché. Dans ce cas, nous pourrions utiliser les `stubs`, qui apparaissent dans l'option de `mount` : `global` en passant `vTooltip`.
+Nous ne voulons pas que le code de la directive `Tooltip` soit exécuté dans ce test, nous souhaitons simplement vérifier que le message est affiché. Dans ce cas, nous pourrions utiliser les `stubs`, qui apparaissent dans l'option de `mount` : `global` en passant `vTooltip`.
```js
test('substitue le composant avec un template personnalisé', () => {
@@ -300,21 +300,21 @@ test('substitue le composant avec un template personnalisé', () => {
// 'directive appelée' affiché dans la console
console.log(wrapper.html());
- // Bienvenue dans Vue.js 3
+ // Bienvenue dans Vue.js 3
- expect(wrapper.classes('with-tooltip')).toBe(true);
+ expect(wrapper.classes('avec-tooltip')).toBe(true);
});
```
-Nous venons juste d'échanger notre implémentation de directive avec la nôtre !
+Nous venons juste d'échanger notre implémentation de directive avec la nôtre !
::: warning
-Le remplacement des directives ne fonctionnera pas sur les composants fonctionnels ou `
```
## Le premier test - une tâche est affichée
-Le premier test que nous allons écrire va vérifier qu'une tâche est affichée. Regardons d'abord le test, puis nous détaillerons chaque partie :
+Le premier test que nous allons écrire va vérifier qu'une tâche est affichée. Regardons d'abord le test, puis nous détaillerons chaque partie :
```js
import { mount } from '@vue/test-utils';
@@ -52,17 +52,17 @@ test('affiche une tâche', () => {
});
```
-Nous commençons par importer `mount` - c'est la principale manière de monter un composant dans VTU. Vous pouvez déclarer un test en utilisant la fonction `test` accompagné d'une courte description pour le test. Les fonctions `test` et `expect` sont disponibles de façon globale dans la plupart des runners de test (cet exemple utilise [Jest](https://jestjs.io/fr/)). Si `test` et `expect` sont des concepts obscurs pour vous, la documentation de Jest a un [exemple plus simple](https://jestjs.io/docs/en/getting-started) de leur utilisation et de leur fonctionnement.
+Nous commençons par importer `mount` - c'est la principale manière de monter un composant dans VTU. Vous pouvez déclarer un test en utilisant la fonction `test` accompagné d'une courte description pour le test. Les fonctions `test` et `expect` sont disponibles de façon globale dans la plupart des gestionnaires de tests (cet exemple utilise [Jest](https://jestjs.io/fr/)). Si `test` et `expect` sont des concepts obscurs pour vous, la documentation de Jest a un [exemple plus simple](https://jestjs.io/docs/en/getting-started) de leur utilisation et de leur fonctionnement.
-Ensuite, nous appelons `mount` et passons le composant en premier argument - c'est quelque chose que la plupart des tests que vous écrirez auront besoin au préalable. Par convention, nous attribuons le résultat à une variable appelée `wrapper`, car `mount` fournit une simple "enveloppe" autour de l'application avec des méthodes utiles pour les tests.
+Ensuite, nous appelons `mount` et passons le composant en premier argument - c'est quelque chose dont la plupart des tests que vous écrirez auront besoin au préalable. Par convention, nous attribuons le résultat à une variable appelée `wrapper`, car `mount` fournit une "enveloppe" simple autour de l'application avec des méthodes utiles pour les tests.
-Enfin, nous utilisons une autre fonction globale courante pour de nombreux runners de tests - Jest inclus - `expect`. L'idée est que nous faisons une vérification, ou une _attente_, que la sortie réelle corresponde à ce que nous pensons qu'elle devrait être. Pour cela, nous cherchons un élément avec le sélecteur `data-test="todo"` - dans le DOM, cela ressemblera à `...`. Nous appelons ensuite la méthode `text` pour obtenir le contenu, que nous attendons être `'Apprendre Vue.js 3'`.
+Enfin, nous utilisons une autre fonction globale courante pour de nombreux gestionnaires de tests - Jest inclus - `expect`. L'idée est que nous faisons une vérification ou une _attente_, que la sortie réelle corresponde à ce que nous pensons qu'elle devrait être. Pour cela, nous cherchons un élément avec le sélecteur `data-test="todo"` - dans le DOM, cela ressemblera à `...`. Nous appelons ensuite la méthode `text` pour obtenir le contenu, que nous attendons être `'Apprendre Vue.js 3'`.
-> L'utilisation de sélecteurs `data-test` n'est pas requise, mais peut rendre vos tests plus solides. Les classes et les id ont tendance à changer ou à se déplacer au fur et à mesure que l'application évolue - en utilisant `data-test`, les autres développeurs comprendront que ce sélecteur est réservé pour les tests, et en doit donc pas être modifié.
+> L'utilisation de sélecteurs `data-test` n'est pas requise, mais peut rendre vos tests plus solides. Les classes et les id ont tendance à changer ou à se déplacer au fur et à mesure que l'application évolue - en utilisant `data-test`, les autres développeurs comprendront que ce sélecteur est réservé pour les tests, et ne doit donc pas être modifié.
## Pour faire passer le test
-Si nous exécutons ce test maintenant, il échouera avec le message d'erreur suivant : `Impossible de trouver [data-test="todo"]`. C'est parce que nous n'affichons aucune tâche, donc l'appel `get()` échoue à renvoyer une enveloppe (rappelez-vous, VTU enveloppe tous les composants et les éléments DOM dans une "enveloppe" avec des méthodes utiles aux tests). Mettez à jour la balise `` dans `TodoApp.vue` pour afficher le tableau des tâches :
+Si nous exécutons ce test maintenant, il échouera avec le message d'erreur suivant : `Impossible de trouver [data-test="todo"]`. C'est parce que nous n'affichons aucune tâche, donc l'appel `get()` échoue à renvoyer une enveloppe (rappelez-vous, VTU place tous les composants et les éléments DOM dans une "enveloppe" avec des méthodes utiles aux tests). Mettez à jour la balise `` dans `TodoApp.vue` pour afficher le tableau des tâches :
```vue
@@ -74,17 +74,17 @@ Si nous exécutons ce test maintenant, il échouera avec le message d'erreur sui
```
-Avec ce changement, le test est passé. Félicitations ! Vous avez écrit votre premier test de composant en utilisant Vue Test Utils.
+Avec ce changement, le test est passé. Félicitations ! Vous avez écrit votre premier test de composant en utilisant Vue Test Utils.
## Ajouter une nouvelle tâche
-La prochaine fonctionnalité que nous allons ajouter est la possibilité pour l'utilisateur de créer une nouvelle tâche. Pour ce faire, nous avons besoin d'un formulaire avec une entrée pour que l'utilisateur puisse taper du texte. Lorsque l'utilisateur soumet le formulaire, nous nous attendons à ce que la nouvelle tâche soit affichée. Regardons le test :
+La prochaine fonctionnalité que nous allons ajouter est la possibilité pour l'utilisateur de créer une nouvelle tâche. Pour ce faire, nous avons besoin d'un formulaire avec une entrée pour que l'utilisateur puisse taper du texte. Lorsque l'utilisateur soumet le formulaire, nous nous attendons à ce que la nouvelle tâche soit affichée. Regardons le test :
```js
import { mount } from '@vue/test-utils';
import TodoApp from './TodoApp.vue';
-test('créer une tâche', () => {
+test('créé une tâche', () => {
const wrapper = mount(TodoApp);
expect(wrapper.findAll('[data-test="todo"]')).toHaveLength(1);
@@ -101,7 +101,7 @@ Pour mettre à jour ``, nous utilisons `setValue` - cela nous permet de d
Après avoir mis à jour ``, nous utilisons la méthode `trigger` pour simuler la soumission du formulaire par l'utilisateur. Enfin, nous vérifions que le nombre d'éléments de la liste de tâches a augmenté de 1 à 2.
-Si nous exécutons ce test, il échouera évidemment. Modifions `TodoApp.vue` pour avoir les éléments `
`. Vous pourriez faire quelque chose comme suit :
```js
const wrapper = mount(ComplexComponent, {
@@ -117,7 +117,7 @@ const wrapper = mount(ComplexComponent, {
});
```
-Mais c'est beaucoup de code répétitif. VTU a une option `mount` : `shallow` qui substituera automatiquement tous les composants enfants :
+Mais c'est beaucoup de code répétitif. VTU a une option `mount` : `shallow` qui substituera automatiquement tous les composants enfants :
```js {3}
test('substitue tous les composants enfants', () => {
@@ -139,13 +139,13 @@ test('substitue tous les composants enfants', () => {
Si vous avez utilisé VTU V1, cela vous rappelle sûrement `shallowMount`. Cette méthode est également toujours disponible, c'est la même chose que d'écrire `shallow: true`.
:::
-## Substituer tous les Composants Enfants avec des Exceptions
+## Substituer tous les composants enfants avec des exceptions
-Parfois, vous voulez remplacer *tous* les composants personnalisés, sauf un en particulier. Voyons un exemple :
+Parfois, vous voulez remplacer *tous* les composants personnalisés, sauf un en particulier. Voyons un exemple :
```js
const ComplexA = {
- template: 'Salutation d\'un composant réel !
'
+ template: 'Salutation d\'un composant réel !
',
};
const ComplexComponent = {
@@ -159,7 +159,7 @@ const ComplexComponent = {
};
```
-En utilisant l'option de `mount` : `shallow`, nous substituons automatiquement tous les composants enfants. Si nous voulons explicitement empêcher la substitution d'un composant spécifique, nous pouvons fournir son nom dans `stubs` avec une valeur définie sur `false`.
+En utilisant l'option de `mount` : `shallow`, nous substituons automatiquement tous les composants enfants. Si nous voulons explicitement empêcher la substitution d'un composant spécifique, nous pouvons fournir son nom dans `stubs` avec une valeur définie sur `false`.
```js {3}
test('l\'option shallow permet de subsituter tous les composants enfants sauf ceux dans stubs', () => {
@@ -182,7 +182,7 @@ test('l\'option shallow permet de subsituter tous les composants enfants sauf ce
## Substituer un Composant Asynchrone
-Si vous voulez substituer un composant asynchrone, il existe deux comportements à prendre en compte. Par exemple, vous pourriez avoir des composants de ce genre :
+Si vous voulez substituer un composant asynchrone, il existe deux comportements à prendre en compte. Par exemple, vous pourriez avoir des composants de ce genre :
```js
// AsyncComponent.js
@@ -222,7 +222,7 @@ Le second comportement consiste à utiliser le nom du composant asynchrone. Dans
Maintenant, il est nécessaire d'utiliser `async/await`, car le composant asynchrone doit être résolu et peut alors être remplacé par le nom défini dans le composant asynchrone.
-**Assurez-vous de définir un nom dans votre composant asynchrone !**
+**Assurez-vous de définir un nom dans votre composant asynchrone !**
```js
test('substitue le composant asynchrone avec résolution', async () => {
@@ -242,9 +242,9 @@ test('substitue le composant asynchrone avec résolution', async () => {
## Substituer une directive
-Parfois, les directives effectuent des opérations assez complexes, comme réaliser beaucoup de manipulation de DOM ce qui peut entraîner des erreurs dans vos tests (en raison de JSDOM ne ressemblant pas au comportement entier du DOM). Un exemple courant sont les directives de tooltip de différentes bibliothèques, qui dépendent généralement fortement de la mesure de la position/taille des nœuds DOM.
+Parfois, les directives effectuent des opérations assez complexes, comme réaliser beaucoup de manipulations de DOM ce qui peut entraîner des erreurs dans vos tests (en raison du JsDOM ne ressemblant pas totalement au DOM). Un exemple courant sont les directives de tooltip de différentes bibliothèques, qui dépendent généralement fortement de la mesure de la position/taille des nœuds DOM.
-Dans cet exemple, nous avons un autre `` qui rend un message dans une infobulle.
+Dans cet exemple, nous avons un autre `` qui affiche un message dans une infobulle.
```js
// directive tooltip déclarée quelque part nommée `Tooltip`
@@ -257,7 +257,7 @@ const App = {
};
```
-Nous ne voulons pas que le code de la directive `Tooltip` soit exécuté dans ce test, nous voulons simplement vérifier que le message est affiché. Dans ce cas, nous pourrions utiliser les `stubs`, qui apparaissent dans l'option de `mount` : `global` en passant `vTooltip`.
+Nous ne voulons pas que le code de la directive `Tooltip` soit exécuté dans ce test, nous souhaitons simplement vérifier que le message est affiché. Dans ce cas, nous pourrions utiliser les `stubs`, qui apparaissent dans l'option de `mount` : `global` en passant `vTooltip`.
```js
test('substitue le composant avec un template personnalisé', () => {
@@ -300,21 +300,21 @@ test('substitue le composant avec un template personnalisé', () => {
// 'directive appelée' affiché dans la console
console.log(wrapper.html());
- // Bienvenue dans Vue.js 3
+ // Bienvenue dans Vue.js 3
- expect(wrapper.classes('with-tooltip')).toBe(true);
+ expect(wrapper.classes('avec-tooltip')).toBe(true);
});
```
-Nous venons juste d'échanger notre implémentation de directive avec la nôtre !
+Nous venons juste d'échanger notre implémentation de directive avec la nôtre !
::: warning
-Le remplacement des directives ne fonctionnera pas sur les composants fonctionnels ou `
```
## Le premier test - une tâche est affichée
-Le premier test que nous allons écrire va vérifier qu'une tâche est affichée. Regardons d'abord le test, puis nous détaillerons chaque partie :
+Le premier test que nous allons écrire va vérifier qu'une tâche est affichée. Regardons d'abord le test, puis nous détaillerons chaque partie :
```js
import { mount } from '@vue/test-utils';
@@ -52,17 +52,17 @@ test('affiche une tâche', () => {
});
```
-Nous commençons par importer `mount` - c'est la principale manière de monter un composant dans VTU. Vous pouvez déclarer un test en utilisant la fonction `test` accompagné d'une courte description pour le test. Les fonctions `test` et `expect` sont disponibles de façon globale dans la plupart des runners de test (cet exemple utilise [Jest](https://jestjs.io/fr/)). Si `test` et `expect` sont des concepts obscurs pour vous, la documentation de Jest a un [exemple plus simple](https://jestjs.io/docs/en/getting-started) de leur utilisation et de leur fonctionnement.
+Nous commençons par importer `mount` - c'est la principale manière de monter un composant dans VTU. Vous pouvez déclarer un test en utilisant la fonction `test` accompagné d'une courte description pour le test. Les fonctions `test` et `expect` sont disponibles de façon globale dans la plupart des gestionnaires de tests (cet exemple utilise [Jest](https://jestjs.io/fr/)). Si `test` et `expect` sont des concepts obscurs pour vous, la documentation de Jest a un [exemple plus simple](https://jestjs.io/docs/en/getting-started) de leur utilisation et de leur fonctionnement.
-Ensuite, nous appelons `mount` et passons le composant en premier argument - c'est quelque chose que la plupart des tests que vous écrirez auront besoin au préalable. Par convention, nous attribuons le résultat à une variable appelée `wrapper`, car `mount` fournit une simple "enveloppe" autour de l'application avec des méthodes utiles pour les tests.
+Ensuite, nous appelons `mount` et passons le composant en premier argument - c'est quelque chose dont la plupart des tests que vous écrirez auront besoin au préalable. Par convention, nous attribuons le résultat à une variable appelée `wrapper`, car `mount` fournit une "enveloppe" simple autour de l'application avec des méthodes utiles pour les tests.
-Enfin, nous utilisons une autre fonction globale courante pour de nombreux runners de tests - Jest inclus - `expect`. L'idée est que nous faisons une vérification, ou une _attente_, que la sortie réelle corresponde à ce que nous pensons qu'elle devrait être. Pour cela, nous cherchons un élément avec le sélecteur `data-test="todo"` - dans le DOM, cela ressemblera à `...`. Nous appelons ensuite la méthode `text` pour obtenir le contenu, que nous attendons être `'Apprendre Vue.js 3'`.
+Enfin, nous utilisons une autre fonction globale courante pour de nombreux gestionnaires de tests - Jest inclus - `expect`. L'idée est que nous faisons une vérification ou une _attente_, que la sortie réelle corresponde à ce que nous pensons qu'elle devrait être. Pour cela, nous cherchons un élément avec le sélecteur `data-test="todo"` - dans le DOM, cela ressemblera à `...`. Nous appelons ensuite la méthode `text` pour obtenir le contenu, que nous attendons être `'Apprendre Vue.js 3'`.
-> L'utilisation de sélecteurs `data-test` n'est pas requise, mais peut rendre vos tests plus solides. Les classes et les id ont tendance à changer ou à se déplacer au fur et à mesure que l'application évolue - en utilisant `data-test`, les autres développeurs comprendront que ce sélecteur est réservé pour les tests, et en doit donc pas être modifié.
+> L'utilisation de sélecteurs `data-test` n'est pas requise, mais peut rendre vos tests plus solides. Les classes et les id ont tendance à changer ou à se déplacer au fur et à mesure que l'application évolue - en utilisant `data-test`, les autres développeurs comprendront que ce sélecteur est réservé pour les tests, et ne doit donc pas être modifié.
## Pour faire passer le test
-Si nous exécutons ce test maintenant, il échouera avec le message d'erreur suivant : `Impossible de trouver [data-test="todo"]`. C'est parce que nous n'affichons aucune tâche, donc l'appel `get()` échoue à renvoyer une enveloppe (rappelez-vous, VTU enveloppe tous les composants et les éléments DOM dans une "enveloppe" avec des méthodes utiles aux tests). Mettez à jour la balise `` dans `TodoApp.vue` pour afficher le tableau des tâches :
+Si nous exécutons ce test maintenant, il échouera avec le message d'erreur suivant : `Impossible de trouver [data-test="todo"]`. C'est parce que nous n'affichons aucune tâche, donc l'appel `get()` échoue à renvoyer une enveloppe (rappelez-vous, VTU place tous les composants et les éléments DOM dans une "enveloppe" avec des méthodes utiles aux tests). Mettez à jour la balise `` dans `TodoApp.vue` pour afficher le tableau des tâches :
```vue
@@ -74,17 +74,17 @@ Si nous exécutons ce test maintenant, il échouera avec le message d'erreur sui
```
-Avec ce changement, le test est passé. Félicitations ! Vous avez écrit votre premier test de composant en utilisant Vue Test Utils.
+Avec ce changement, le test est passé. Félicitations ! Vous avez écrit votre premier test de composant en utilisant Vue Test Utils.
## Ajouter une nouvelle tâche
-La prochaine fonctionnalité que nous allons ajouter est la possibilité pour l'utilisateur de créer une nouvelle tâche. Pour ce faire, nous avons besoin d'un formulaire avec une entrée pour que l'utilisateur puisse taper du texte. Lorsque l'utilisateur soumet le formulaire, nous nous attendons à ce que la nouvelle tâche soit affichée. Regardons le test :
+La prochaine fonctionnalité que nous allons ajouter est la possibilité pour l'utilisateur de créer une nouvelle tâche. Pour ce faire, nous avons besoin d'un formulaire avec une entrée pour que l'utilisateur puisse taper du texte. Lorsque l'utilisateur soumet le formulaire, nous nous attendons à ce que la nouvelle tâche soit affichée. Regardons le test :
```js
import { mount } from '@vue/test-utils';
import TodoApp from './TodoApp.vue';
-test('créer une tâche', () => {
+test('créé une tâche', () => {
const wrapper = mount(TodoApp);
expect(wrapper.findAll('[data-test="todo"]')).toHaveLength(1);
@@ -101,7 +101,7 @@ Pour mettre à jour ``, nous utilisons `setValue` - cela nous permet de d
Après avoir mis à jour ``, nous utilisons la méthode `trigger` pour simuler la soumission du formulaire par l'utilisateur. Enfin, nous vérifions que le nombre d'éléments de la liste de tâches a augmenté de 1 à 2.
-Si nous exécutons ce test, il échouera évidemment. Modifions `TodoApp.vue` pour avoir les éléments `
Bienvenue dans Vue.js 3
+ //Bienvenue dans Vue.js 3
- expect(wrapper.classes('with-tooltip')).toBe(true); + expect(wrapper.classes('avec-tooltip')).toBe(true); }); ``` -Nous venons juste d'échanger notre implémentation de directive avec la nôtre ! +Nous venons juste d'échanger notre implémentation de directive avec la nôtre ! ::: warning -Le remplacement des directives ne fonctionnera pas sur les composants fonctionnels ou ` ``` ## Le premier test - une tâche est affichée -Le premier test que nous allons écrire va vérifier qu'une tâche est affichée. Regardons d'abord le test, puis nous détaillerons chaque partie : +Le premier test que nous allons écrire va vérifier qu'une tâche est affichée. Regardons d'abord le test, puis nous détaillerons chaque partie : ```js import { mount } from '@vue/test-utils'; @@ -52,17 +52,17 @@ test('affiche une tâche', () => { }); ``` -Nous commençons par importer `mount` - c'est la principale manière de monter un composant dans VTU. Vous pouvez déclarer un test en utilisant la fonction `test` accompagné d'une courte description pour le test. Les fonctions `test` et `expect` sont disponibles de façon globale dans la plupart des runners de test (cet exemple utilise [Jest](https://jestjs.io/fr/)). Si `test` et `expect` sont des concepts obscurs pour vous, la documentation de Jest a un [exemple plus simple](https://jestjs.io/docs/en/getting-started) de leur utilisation et de leur fonctionnement. +Nous commençons par importer `mount` - c'est la principale manière de monter un composant dans VTU. Vous pouvez déclarer un test en utilisant la fonction `test` accompagné d'une courte description pour le test. Les fonctions `test` et `expect` sont disponibles de façon globale dans la plupart des gestionnaires de tests (cet exemple utilise [Jest](https://jestjs.io/fr/)). Si `test` et `expect` sont des concepts obscurs pour vous, la documentation de Jest a un [exemple plus simple](https://jestjs.io/docs/en/getting-started) de leur utilisation et de leur fonctionnement. -Ensuite, nous appelons `mount` et passons le composant en premier argument - c'est quelque chose que la plupart des tests que vous écrirez auront besoin au préalable. Par convention, nous attribuons le résultat à une variable appelée `wrapper`, car `mount` fournit une simple "enveloppe" autour de l'application avec des méthodes utiles pour les tests. +Ensuite, nous appelons `mount` et passons le composant en premier argument - c'est quelque chose dont la plupart des tests que vous écrirez auront besoin au préalable. Par convention, nous attribuons le résultat à une variable appelée `wrapper`, car `mount` fournit une "enveloppe" simple autour de l'application avec des méthodes utiles pour les tests. -Enfin, nous utilisons une autre fonction globale courante pour de nombreux runners de tests - Jest inclus - `expect`. L'idée est que nous faisons une vérification, ou une _attente_, que la sortie réelle corresponde à ce que nous pensons qu'elle devrait être. Pour cela, nous cherchons un élément avec le sélecteur `data-test="todo"` - dans le DOM, cela ressemblera à `...
`. Nous appelons ensuite la méthode `text` pour obtenir le contenu, que nous attendons être `'Apprendre Vue.js 3'`.
+Enfin, nous utilisons une autre fonction globale courante pour de nombreux gestionnaires de tests - Jest inclus - `expect`. L'idée est que nous faisons une vérification ou une _attente_, que la sortie réelle corresponde à ce que nous pensons qu'elle devrait être. Pour cela, nous cherchons un élément avec le sélecteur `data-test="todo"` - dans le DOM, cela ressemblera à `...
`. Nous appelons ensuite la méthode `text` pour obtenir le contenu, que nous attendons être `'Apprendre Vue.js 3'`.
-> L'utilisation de sélecteurs `data-test` n'est pas requise, mais peut rendre vos tests plus solides. Les classes et les id ont tendance à changer ou à se déplacer au fur et à mesure que l'application évolue - en utilisant `data-test`, les autres développeurs comprendront que ce sélecteur est réservé pour les tests, et en doit donc pas être modifié.
+> L'utilisation de sélecteurs `data-test` n'est pas requise, mais peut rendre vos tests plus solides. Les classes et les id ont tendance à changer ou à se déplacer au fur et à mesure que l'application évolue - en utilisant `data-test`, les autres développeurs comprendront que ce sélecteur est réservé pour les tests, et ne doit donc pas être modifié.
## Pour faire passer le test
-Si nous exécutons ce test maintenant, il échouera avec le message d'erreur suivant : `Impossible de trouver [data-test="todo"]`. C'est parce que nous n'affichons aucune tâche, donc l'appel `get()` échoue à renvoyer une enveloppe (rappelez-vous, VTU enveloppe tous les composants et les éléments DOM dans une "enveloppe" avec des méthodes utiles aux tests). Mettez à jour la balise `` dans `TodoApp.vue` pour afficher le tableau des tâches :
+Si nous exécutons ce test maintenant, il échouera avec le message d'erreur suivant : `Impossible de trouver [data-test="todo"]`. C'est parce que nous n'affichons aucune tâche, donc l'appel `get()` échoue à renvoyer une enveloppe (rappelez-vous, VTU place tous les composants et les éléments DOM dans une "enveloppe" avec des méthodes utiles aux tests). Mettez à jour la balise `` dans `TodoApp.vue` pour afficher le tableau des tâches :
```vue
@@ -74,17 +74,17 @@ Si nous exécutons ce test maintenant, il échouera avec le message d'erreur sui
```
-Avec ce changement, le test est passé. Félicitations ! Vous avez écrit votre premier test de composant en utilisant Vue Test Utils.
+Avec ce changement, le test est passé. Félicitations ! Vous avez écrit votre premier test de composant en utilisant Vue Test Utils.
## Ajouter une nouvelle tâche
-La prochaine fonctionnalité que nous allons ajouter est la possibilité pour l'utilisateur de créer une nouvelle tâche. Pour ce faire, nous avons besoin d'un formulaire avec une entrée pour que l'utilisateur puisse taper du texte. Lorsque l'utilisateur soumet le formulaire, nous nous attendons à ce que la nouvelle tâche soit affichée. Regardons le test :
+La prochaine fonctionnalité que nous allons ajouter est la possibilité pour l'utilisateur de créer une nouvelle tâche. Pour ce faire, nous avons besoin d'un formulaire avec une entrée pour que l'utilisateur puisse taper du texte. Lorsque l'utilisateur soumet le formulaire, nous nous attendons à ce que la nouvelle tâche soit affichée. Regardons le test :
```js
import { mount } from '@vue/test-utils';
import TodoApp from './TodoApp.vue';
-test('créer une tâche', () => {
+test('créé une tâche', () => {
const wrapper = mount(TodoApp);
expect(wrapper.findAll('[data-test="todo"]')).toHaveLength(1);
@@ -101,7 +101,7 @@ Pour mettre à jour ``, nous utilisons `setValue` - cela nous permet de d
Après avoir mis à jour ``, nous utilisons la méthode `trigger` pour simuler la soumission du formulaire par l'utilisateur. Enfin, nous vérifions que le nombre d'éléments de la liste de tâches a augmenté de 1 à 2.
-Si nous exécutons ce test, il échouera évidemment. Modifions `TodoApp.vue` pour avoir les éléments `