diff --git a/docs/en/guides/choosing-a-test-runner.md b/docs/en/guides/choosing-a-test-runner.md index 692264d5d..0459d6ff9 100644 --- a/docs/en/guides/choosing-a-test-runner.md +++ b/docs/en/guides/choosing-a-test-runner.md @@ -1,45 +1,45 @@ -# Choosing a test runner +# Choisir un lanceur de tests -A test runner is a program that runs tests. +Un lanceur de tests est un programme qui lance des tests (et oui !). -There are many popular JavaScript test runners, and `vue-test-utils` works with all of them. It's test runner agnostic. +Il y a un nombre conséquent de lanceurs de tests JavaScript et `vue-test-utils` marche avec tous ceux d'entre eux. `vue-test-utils` est agnostique de lanceurs de tests. -There are a few things to consider when choosing a test runner though: feature set, performance, and support for single-file component (SFC) pre-compilation. After carefully comparing existing libraries, here are two test runners that we recommend: +Il y a tout de même plusieurs choses à considérer afin de choisir un lanceur de tests : variété des fonctionnalités, performance et support de la pré-compilation des composants monofichiers (SFC). Après avoir cautionnement analysé et comparé les bibliothèques, il y a deux lanceurs de tests que nous recommandons : -- [Jest](https://facebook.github.io/jest/docs/en/getting-started.html#content) is the most fully featured test runner. It requires the least configuration, sets up JSDOM by default, provides built-in assertions, and has a great command line user experience. However, you will need a preprocessor to be able to import SFC components in your tests. We have created the `jest-vue` preprocessor which can handle most common SFC features, but it currently does not have 100% feature parity with `vue-loader`. +- [Jest](https://facebook.github.io/jest/docs/en/getting-started.html#content) est le lanceur de test le plus complet en terme de fonctionnalités. Il requiert une configuration minimale, installe JSDOM par défaut, fournit des assertions prêtes à l'usage et a une très bonne interface en ligne de commandes. Cependant, vous allez avoir besoin d'un pré-processeur afin d'être capable d'importer les composants monofichiers dans nos tests. On a créé le préprocesseur `jest-vue` qui peut gérer les fonctionnalités communes des composants monofichiers. Il n'y a cependant pas encore autant de fonctionnalités que vue-loader. -- [mocha-webpack](https://github.com/zinserjan/mocha-webpack) is a wrapper around webpack + Mocha, but with a more streamlined interface and watch mode. The benefits of this setup is that we can get complete SFC support via webpack + `vue-loader`, but it requires more configuration upfront. +- [mocha-webpack](https://github.com/zinserjan/mocha-webpack) est une surcouche de webpack + Mocha avec une expérience simplifiée et un mode de surveillance. Les bénéfices de cette installation sont que l'on peut avoir le support complet des composants monofichiers via webpack + `vue-loader`. Il y a cependant plus de configurations à réaliser. -## Browser Environment +## Environnement du navigateur -`vue-test-utils` relies on a browser environment. Technically you can run it in a real browser, but it's not recommended due to the complexity of launching real browsers on different platforms. Instead, we recommend running the tests in Node.js with a virtual browser environment using [JSDOM](https://github.com/tmpvar/jsdom). +`vue-test-utils` se fie à un environnement de navigateur. Techniquement, vous pouvez le lancer dans un vrai navigateur, mais cela n'est pas recommandé dû à la complexité de lancer de réels navigateur sur différentes plateformes. Au lieu de cela, nous recommandons de lancer les tests sous Node.js avec un environnement virtuel de navigateur en utilisant le [JSDOM](https://github.com/tmpvar/jsdom). -The Jest test runner sets up JSDOM automatically. For other test runners, you can manually set up JSDOM for the tests using [jsdom-global](https://github.com/rstacruz/jsdom-global) in the entry for your tests: +Le lanceur de tests Jest installe automatiquement JSDOM. Pour d'autres lanceurs de tests, il faut le faire manuellement en utilisant [jsdom-global](https://github.com/rstacruz/jsdom-global) dans la déclaration de vos tests : ``` bash npm install --save-dev jsdom jsdom-global ``` --- ``` js -// in test setup / entry +// dans test setup / entry require('jsdom-global')() ``` -## Testing Single-File Components +## Tester des composants monofichiers -Single-file Vue components (SFCs) require pre-compilation before they can be run in Node or in the browser. There are two recommended ways to perform the compilation: with a Jest preprocessor, or directly use webpack. +Les composants Vue monofichiers (SFC) nécessites une étape de pré-compilation avant qu'ils soient lancés dans Node ou sur un navigateur. Il y a deux manières de faire qui sont recommandées pour réaliser la compilation : avec un préprocesseur Jest ou directement en utilisant webpack. -The `jest-vue` preprocessor supports basic SFC functionalities, but currently does not handle style blocks or custom blocks, which are only supported in `vue-loader`. If you rely on these features or other webpack-specific configurations, you will need to use a webpack + `vue-loader` based setup. +Le préprocesseur `jest-vue` supporte les fonctionnalités basiques des composants monofichiers. Il ne gère pas actuellement les blocs de style et les blocs personnalisés, qui sont eux uniquement supportés par `vue-loader`. Si vous utilisez ces fonctionnalités ou d'autres configurations liées à webpack, vous aurez besoin d'utiliser l'installation basée sur webpack + `vue-loader` -Read the following guides for different setups: +Lisez les guides suivants pour différentes installations : -- [Testing SFCs with Jest](./testing-SFCs-with-jest.md) -- [Testing SFCs with Mocha + webpack](./testing-SFCs-with-mocha-webpack.md) +- [Tester des composants monofichiers avec Jest](./testing-SFCs-with-jest.md) +- [Tester des composants monofichiers avec Mocha + webpack](./testing-SFCs-with-mocha-webpack.md) -## Resources +## Ressources -- [Test runner performance comparison](https://github.com/eddyerburgh/vue-unit-test-perf-comparison) -- [Example project with Jest](https://github.com/vuejs/vue-test-utils-jest-example) -- [Example project with Mocha](https://github.com/vuejs/vue-test-utils-mocha-webpack-example) -- [Example project with tape](https://github.com/eddyerburgh/vue-test-utils-tape-example) -- [Example project with AVA](https://github.com/eddyerburgh/vue-test-utils-ava-example) +- [Comparaison de lanceurs de tests](https://github.com/eddyerburgh/vue-unit-test-perf-comparison) +- [Projet exemple avec Jest](https://github.com/vuejs/vue-test-utils-jest-example) +- [Projet exemple avec Mocha](https://github.com/vuejs/vue-test-utils-mocha-webpack-example) +- [Projet exemple avec tape](https://github.com/eddyerburgh/vue-test-utils-tape-example) +- [Projet exemple avec AVA](https://github.com/eddyerburgh/vue-test-utils-ava-example) diff --git a/docs/en/guides/common-tips.md b/docs/en/guides/common-tips.md index abd7500a7..8fae95497 100644 --- a/docs/en/guides/common-tips.md +++ b/docs/en/guides/common-tips.md @@ -1,68 +1,67 @@ -# Common Tips +# Astuces -## Knowing What to Test +## Savoir quoi tester -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. +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. -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). +À 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 boite 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). -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. +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). -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. +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. -This topic is discussed with more details in a [great presentation by Matt O'Connell](http://slides.com/mattoconnell/deck#/). +Ce sujet est discuté plus en détail dans une [très bonne présentation de Matt O'Connell](http://slides.com/mattoconnell/deck#/). -## Shallow Rendering +## Rendu superficiel -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. +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. -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. +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. -`vue-test-utils` allows you to mount a component without rendering its child components (by stubbing them) with the `shallow` method: +`vue-test-utils` vous permets de monter un composant sans avoir à rendre ses composants enfants (en les ignorants) avec la méthode `shallow` : ```js import { shallow } from 'vue-test-utils' -const wrapper = shallow(Component) // returns a Wrapper containing a mounted Component instance -wrapper.vm // the mounted Vue instance +const wrapper = shallow(Component) // retourne un wrapper contenant une instance de composant montée +wrapper.vm // l'instance de Vue montée ``` -## Asserting Emitted Events +## Assertion d'évènements émis -Each mounted wrapper automatically records all events emitted by the underlying Vue instance. You can retrieve the recorded events using the `wrapper.emitted()` method: +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()` : ``` js wrapper.vm.$emit('foo') wrapper.vm.$emit('foo', 123) /* -wrapper.emitted() returns the following object: +`wrapper.emitted()` retourne l'objet suivant : { foo: [[], [123]] } */ ``` -You can then make assertions based on these data: - +Vous pouvez ensuite réaliser des assertions sur ces données : ``` js import { expect } from 'chai' -// assert event has been emitted +// asserte que l'évènement est bien émit expect(wrapper.emitted().foo).toBeTruthy() -// assert event count +// asserte la taille du compteur d'évènement expect(wrapper.emitted().foo.length).toBe(2) -// assert event payload +// asserte le contenu lié à l'évènement expect(wrapper.emitted().foo[1]).toEqual([123]) ``` -You can also get an Array of the events in their emit order by calling [wrapper.emittedByOrder()](../api/wrapper/emittedByOrder.md). +Vous pouvez aussi récupérer un tableau des évènements dans l'ordre d'émission en appelant [`wrapper.emittedByOrder()`](../api/wrapper/emittedByOrder.md). -## Manipulating Component State +## Manipuler l'état d'un composant -You can directly manipulate the state of the component using the `setData` or `setProps` method on the wrapper: +Vous pouvez directement manipuler l'état d'un composant en utilisant la méthode `setData` ou `setProps` sur le wrapper : ```js wrapper.setData({ count: 10 }) @@ -70,48 +69,48 @@ wrapper.setData({ count: 10 }) wrapper.setProps({ foo: 'bar' }) ``` -## Mocking Props +## Simuler des props -You can pass props to the component using Vue's built-in `propsData` option: +Vous pouvez passer des props au composant en utilisant l'option `propsData` de Vue : ```js import { mount } from 'vue-test-utils' mount(Component, { propsData: { - aProp: 'some value' + aProp: 'une valeur' } }) ``` -You can also update the props of an already-mounted component with the `wrapper.setProps({})` method. +Vous pouvez aussi mettre à jour les props d'un composant déjà monté avec la méthode `wrapper.setProps({})`. -*For a full list of options, please see the [mount options section](../api/options.md) of the docs.* +*Pour une liste complète des options, veuillez regarder [la section sur les options de montage](../api/options.md) de la documentation.* -## Applying Global Plugins and Mixins +## Appliquer des plugins globaux et des mixins -Some of the components may rely on features injected by a global plugin or mixin, for example `vuex` and `vue-router`. +Des composants pourraient se fier à des fonctionnalités injectées par un plugin global ou un mixin, par exemple `vuex` ou `vue-router`. -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: +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 : ``` js import createLocalVue from 'vue-test-utils' -// create an extended Vue constructor +// créer un constructeur local de Vue const localVue = createLocalVue() -// install plugins as normal +// installer des plugins comme d'habitude localVue.use(MyPlugin) -// pass the localVue to the mount options +// passe la `localVue` aux options de montage mount(Component, { localVue }) ``` -## Mocking Injections +## Simuler des injections -Another strategy for injected properties is simply mocking them. You can do that with the `mocks` option: +Une stratégie alternative pour injecter des propriétés est de simplement les simuler. Vous pouvez faire cela avec l'option `mocks` : ```js import { mount } from 'vue-test-utils' @@ -120,16 +119,16 @@ const $route = { path: '/', hash: '', params: { id: '123' }, - query: { q: 'hello' } + query: { q: 'bonjour' } } mount(Component, { mocks: { - $route // adds the mocked $route object to the Vue instance before mounting component + $route // ajoute l'objet route simulé à l'instance de Vue avant de monter le composant } }) ``` -## Dealing with Routing +## Gérer le routage -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. +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 bout en bout (« end-to-end »). Pour des composants individuels qui se fient aux fonctionnalités de `vue-router`, vous pouvez les simuler en utilisant les techniques mentionnées plus haut. diff --git a/docs/en/guides/getting-started.md b/docs/en/guides/getting-started.md index 5c023d6dc..b70e74952 100644 --- a/docs/en/guides/getting-started.md +++ b/docs/en/guides/getting-started.md @@ -1,8 +1,8 @@ -# Getting Started +# Pour commencer -## Setup +## Installation -To get a quick taste of using `vue-test-utils`, clone our demo repository with basic setup and install the dependencies: +Pour avoir un rapide avant goût de `vue-test-utils`, clonez notre répertoire de démontration avec l'installation de base puis installez les dépendances : ``` bash git clone https://github.com/vuejs/vue-test-utils-getting-started @@ -10,7 +10,7 @@ cd vue-test-utils-getting-started npm install ``` -You will see that the project includes a simple component, `counter.js`: +Vous allez voir que le projet possède un simple composant, `counter.js` : ```js // counter.js @@ -37,64 +37,64 @@ export default { } ``` -### Mounting Components +### Montages de composants -`vue-test-utils` tests Vue components by mounting them in isolation, mocking the necessary inputs (props, injections and user events) and asserting the outputs (render result, emitted custom events). +`vue-test-utils` teste les composants Vue en les isolants puis en les montant, il simule les entrées nécessaires (props, injections et événements utilisateur) et asserte les sorties (le rendu, les événements émis). -Mounted components are returned inside a [Wrapper](./api/wrapper.md), which exposes many convenience methods for manipulating, traversing and querying the underlying Vue component instance. +Les composants montés sont retournés sous un [Wrapper](./api/wrapper.md), qui expose en quantité des méthodes pour manipuler, traverser et interroger l'instance du composant Vue en question. -You can create wrappers using the `mount` method. Let's create a file called `test.js`: +Vous pouvez créer des wrappers en utilisant la méthode `mount`. Créons un fichier nommé `test.js` : ```js // test.js -// Import the mount() method from the test utils -// and the component you want to test +// Importe la méthode mount() depuis test utils +// et le composant qu'on souhaite tester import { mount } from 'vue-test-utils' import Counter from './counter' -// Now mount the component and you have the wrapper +// On monte le composant et nous voilà avec un wrapper const wrapper = mount(Counter) -// You can access the actual Vue instance via wrapper.vm +// On accède à l'instance actuelle de Vue via wrapper.vm const vm = wrapper.vm -// To inspect the wrapper deeper just log it to the console -// and your adventure with the vue-test-utils begins +// Pour inspecter le wrapper en profondeur, utilisez console +// puis l'aventure avec vue-test-utils commence ! console.log(wrapper) ``` -### Test rendered HTML output of the component +### Tester le contenu du rendu HTML d'un composant -Now that we have the wrapper, the first thing we can do is to verify that the rendered HTML output of the component matches what is expected. +Nous avons maintenant un wrapper, la première chose que l'on peut faire et de vérifier que le contenu du rendu HTML du composant correspond à ce qu'il est sensé être. ```js import { mount } from 'vue-test-utils' import Counter from './counter' describe('Counter', () => { - // Now mount the component and you have the wrapper + // On monte le composant et nous voilà avec un wrapper const wrapper = mount(Counter) - it('renders the correct markup', () => { + it('fait le rendu correctement', () => { expect(wrapper.html()).toContain('0') }) - // it's also easy to check for the existence of elements - it('has a button', () => { + // c'est auss très simple de vérifier qu'un élement existe + it('a un bouton', () => { expect(wrapper.contains('button')).toBe(true) }) }) ``` -Now run the tests with `npm test`. You should see the tests passing. +On peut maintenant lancer les tests avec `npm test`. Vous devriez voir les tests se lancer et réussir. -### Simulating User Interaction +### Simuler des interactions utilisateur -Our counter should increment the count when the user clicks the button. To simulate the behavior, we need to first locate the button with `wrapper.find()`, which returns a **wrapper for the button element**. We can then simulate the click by calling `.trigger()` on the button wrapper: +Notre compteur devrait s'incrémenter quand l'utilisateur clique sur le bouton. Pour simuler ce comportement, on doit tout d'abord localiser le bouton avec `wrapper.find()`, qui retourne un **wrapper pour l'élément bouton**. On peut ensuite simuler un clic en appelant `.trigger()` sur le wrapper du bouton : ```js -it('button click should increment the count', () => { +it('le clic sur le bouton devrait incrémenter le compteur', () => { expect(wrapper.vm.count).toBe(0) const button = wrapper.find('button') button.trigger('click') @@ -102,15 +102,15 @@ it('button click should increment the count', () => { }) ``` -### What about `nextTick`? +### Et quid de `nextTick` ? -Vue batches pending DOM updates and applies them asynchronously to prevent unnecessary re-renders caused by multiple data mutations. This is why in practice we often have to use `Vue.nextTick` to wait until Vue has performed the actual DOM update after we trigger some state change. +Vue groupe les mises à jour du DOM en attentes puis les appliquent de façon asynchrone pour prévenir d'éventuel multiples rendus causé par de multiples mutations de données. C'est pourquoi en pratique, on a souvent à utiliser `Vue.nextTick` pour attendre que Vue modifie le DOM actuel après avoir lancé quelques changements d'état. -To simplify usage, `vue-test-utils` applies all updates synchronously so you don't need to use `Vue.nextTick` to wait for DOM updates in your tests. +Pour simplifier cela, `vue-test-utils` applique toutes les mises à jour de façon synchrone afin que vous n'ayez pas besin d'utiliser `Vue.nextTick` pour attendre des mises à jour du DOM dans vos tests. -*Note: `nextTick` is still necessary when you need to explictly advance the event loop, for operations such as asynchronous callbacks or promise resolution.* +*Note : `nextTick` est encore nécessaire quand vous souhaitez explicitement faire avancer la boucle des événements, pour des opérations telles que des fonctions de rappel ou des résolutions de promise.* -## What's Next +## Et après ? -- Integrate `vue-test-utils` into your project by [choosing a test runner](./choosing-a-test-runner.md) -- Learn more about [common techniques when writing tests](./common-tips.md) +- Intégrer `vue-test-utils` dans votre projet en [choisissant votre lanceur de tests](./choosing-a-test-runner.md) +- En apprendre plus sur les [techniques et astuces pour écrire des tests](./common-tips.md) diff --git a/docs/en/guides/testing-SFCs-with-jest.md b/docs/en/guides/testing-SFCs-with-jest.md index 0bd70718d..6e54e76e5 100644 --- a/docs/en/guides/testing-SFCs-with-jest.md +++ b/docs/en/guides/testing-SFCs-with-jest.md @@ -1,20 +1,20 @@ -# Testing Single File Components with Jest +# Tester des composants monofichiers avec Jest -> An example project for this setup is available on [GitHub](https://github.com/vuejs/vue-test-utils-jest-example). +> Un projet exemple pour cette installation est disponible sur [GitHub](https://github.com/vuejs/vue-test-utils-jest-example). -Jest is a test runner developed by Facebook, aiming to deliver a battery-included unit testing solution. You can learn more about Jest on its [official documentation](https://facebook.github.io/jest/). +Jest est un lanceur de tests développé par Facebook. Il a pour but de procurer une solution complète de tests unitaire. Vous pouvez en apprendre plus sur Jest sur [sa documentation officielle](https://facebook.github.io/jest/). -## Setting up Jest +## Installer Jest -We will assume you are starting with a setup that already has webpack, vue-loader and Babel properly configured - e.g. the `webpack-simple` template scaffolded by `vue-cli`. +On va supposer que vous commencez avec une installation qui a déjà webpack, vue-loader et Babel de correctement configurés (cf. le template `webpack-simple` via `vue-cli`). -The first thing to do is install Jest and `vue-test-utils`: +La première chose à faire est d'installer Jest et `vue-test-utils` : ```bash $ npm install --save-dev jest vue-test-utils ``` -Next we need to define a unit script in our `package.json`. +Ensuite, on doit définir un script dans notre `package.json`. ```json // package.json @@ -25,15 +25,15 @@ Next we need to define a unit script in our `package.json`. } ``` -## Processing SFCs in Jest +## Traiter les composants monofichiers dans Jest -To teach Jest how to process `*.vue` files, we will need to install and configure the `jest-vue` preprocessor: +Pour indiquer à Jest comment traiter les fichiers `*.vue`, on va avoir besoin d'installer et de configurer le pré-processeur `jest-vue` : ``` bash npm install --save-dev jest-vue ``` -Next, create a `jest` block in `package.json`: +Ensuite, créez un objet `jest` dans `package.json` : ``` json { @@ -42,11 +42,11 @@ Next, create a `jest` block in `package.json`: "moduleFileExtensions": [ "js", "json", - // tell Jest to handle *.vue files + // indique à Jest de gérer les fichiers *.vue "vue" ], "transform": { - // process *.vue files with jest-vue + // traite les fichiers *.vue avec jest-vue ".*\\.(vue)$": "/node_modules/jest-vue" }, "mapCoverage": true @@ -54,18 +54,18 @@ Next, create a `jest` block in `package.json`: } ``` -> **Note:** `jest-vue` currently does not support all the features of `vue-loader`, for example custom block support and style loading. In addition, some webpack-specific features such as code-splitting are not supported either. To use them, read the guide on [testing SFCs with Mocha + webpack](./testing-SFCs-with-mocha-webpack.md). +> **Note :** `jest-vue` ne supporte actuellement pas toutes les fonctionnalités de `vue-loader`, par exemple le support des blocs personalisés et du chargement de styles. De plus, quelques fonctionnalités spécifique à webpack comme le découpage du code ne sont pas supportées. Pour les utiliser, lisez le guide sur [tester des composants monofichiers avec Mocha + webpack](./testing-SFCs-with-mocha-webpack.md). -## Handling webpack Aliases +## Gérer les alias webpack -If you use a resolve alias in the webpack config, e.g. aliasing `@` to `/src`, you need to add a matching config for Jest as well, using the `moduleNameMapper` option: +Si vous utilisez un alias de résolution dans la configuration de webpack, c.à.d faire un alias `@` pour `/src`, vous devez aussi ajouter une configuration pour Jest en utilisant l'option `moduleNameMapper` : ``` json { // ... "jest": { // ... - // support the same @ -> src alias mapping in source code + // gère le même alias dans le code @ -> src "moduleNameMapper": { "^@/(.*)$": "/src/$1" } @@ -73,15 +73,15 @@ If you use a resolve alias in the webpack config, e.g. aliasing `@` to `/src`, y } ``` -## Configuring Babel for Jest +## Configurer Babel pour Jest -Although latest versions of Node already supports most ES2015 features, you may still want to use ES modules syntax and stage-x features in your tests. For that we need to install `babel-jest`: +Même si les dernières versions de Node supportent la plupart des fonctionnalités ES2015, vous souhaitez quand même utiliser la syntaxe des modules ES ainsi que les fonctionnalités stage-x dans vos tests. Pour cela, on doit installer `babel-jest` : ``` bash npm install --save-dev babel-jest ``` -Next, we need to tell Jest to process JavaScript test files with `babel-jest` by adding an entry under `jest.transform` in `package.json`: +Ensuite, on doit indiquer à Jest de gérer les fichiers de tests JavaScript avec `babel-jest` en ajoutant une entrée sous `jest.transform` dans `package.json` : ``` json { @@ -90,7 +90,7 @@ Next, we need to tell Jest to process JavaScript test files with `babel-jest` by // ... "transform": { // ... - // process js with babel-jest + // gèrer le JavaScript avec babel-jest "^.+\\.js$": "/node_modules/babel-jest" }, // ... @@ -98,15 +98,15 @@ Next, we need to tell Jest to process JavaScript test files with `babel-jest` by } ``` -> By default, `babel-jest` automatically configures itself as long as it's installed. However, because we have explicitly added a transform for `*.vue` files, we now need to explicitly configure `babel-jest` as well. +> Par défaut, `babel-jest` va automatiquement s'auto-configurer dès l'installation. Cependant, comme nous avons explicitement ajouté une transformation pour les fichiers `*.vue`, on se doit aussi d'explicitement configurer `babel-jest`. -Assuming using `babel-preset-env` with webpack, the default Babel config disables ES modules transpilation because webpack already knows how to handle ES modules. However, we do need to enable it for our tests because Jest tests run directly in Node. +En assumant que vous utilisez `babel-preset-env` avec webpack, la configuration par défaut de Babel désactive la transpilation des modules ES car webpack sait déjà comment traiter ces modules. Nous devons, cependant, l'activer pour nos tests car, Jest fonctionne directement dans Node. -Also, we can tell `babel-preset-env` to target the Node version we are using. This skips transpiling unnecessary features and makes our tests boot faster. +On doit aussi indiquer à `babel-preset-env` d'utiliser la version de Node que nous utilisons. Cela empêchera de transpiler inutilement des fonctionnalités et lancera nos tests plus rapidement. -To apply these options only for tests, put them in a separate config under `env.test` (this will be automatically picked up by `babel-jest`). +Pour appliquer ces options uniquement aux tests, mettez les dans un fichier de configuration différent sous `env.test` (cela va être automatiquement être utilisé par `babel-jest`). -Example `.babelrc`: +Exemple `.babelrc`: ``` json { @@ -123,24 +123,24 @@ Example `.babelrc`: } ``` -### Snapshot Testing +### Test d'instantanés -You can use [`vue-server-renderer`](https://github.com/vuejs/vue/tree/dev/packages/vue-server-renderer) to render a component into a string so that it can be saved as a snapshot for [Jest snapshot testing](https://facebook.github.io/jest/docs/en/snapshot-testing.html). +Vous pouvez utiliser [`vue-server-renderer`](https://github.com/vuejs/vue/tree/dev/packages/vue-server-renderer) pour transformer un composant en une chaîne de caractères afin de le sauvegarder dans un instantané pour [Jest tests d'instantanés](https://facebook.github.io/jest/docs/en/snapshot-testing.html). -The render result of `vue-server-renderer` includes a few SSR-specific attributes, and it ignores whitespaces, making it harder to scan a diff. We can improve the saved snapshot with a custom serializer: +Le résultat du rendu de `vue-server-renderer` inclut quelques attributs spécifiques au rendu côté serveur. Il ignore les espaces, cela rend plus dur d'analyser une différence. On peut améliorer l'instantané sauvegardé avec un sérialiseur personnalisé : ``` bash npm install --save-dev jest-serializer-vue ``` -Then configure it in `package.json`: +Puis configurez le dans `package.json`: ``` json { // ... "jest": { // ... - // serializer for snapshots + // serialiseur pour les instantanés "snapshotSerializers": [ "/node_modules/jest-serializer-vue" ] @@ -148,31 +148,31 @@ Then configure it in `package.json`: } ``` -### Placing Test Files +### Placer les fichiers de tests -By default, jest will recursively pick up all files that have a `.spec.js` or `.test.js` extension in the entire project. If this does not fit your needs, it's possible [to change the testRegex](https://facebook.github.io/jest/docs/en/configuration.html#testregex-string) in the config section in the `package.json` file. +Par défaut, Jest va récursivement récupérer tous les fichier qui ont une extension en `.spec.js` ou `.test.js` dans le projet. Si cela ne correspond pas à vos besoins, il est possible [de changer l'expression régulière testRegex](https://facebook.github.io/jest/docs/en/configuration.html#testregex-string) dans la configuration se trouvant dans `package.json`. -Jest recommends creating a `__tests__` directory right next to the code being tested, but feel free to structure your tests as you see fit. Just beware that Jest would create a `__snapshots__` directory next to test files that performs snapshot testing. +Jest recommande de créer un répertoire `__tests__` au même niveau que le code testé, mais soyez libre de structurer vos tests selon vos besoins. Soyez juste au courant que Jest créera un répertoire `__snapshots__` au même niveau que les fichiers de tests qui travaillent sur des instantanés. -### Example Spec +### Exemple d'une spécification -If you are familiar with Jasmine, you should feel right at home with Jest's [assertion API](https://facebook.github.io/jest/docs/en/expect.html#content): +Si vous êtes habitué à Jasmine, vous devriez très bien vous en sortir avec [l'API d'assertions de Jest](https://facebook.github.io/jest/docs/en/expect.html#content) : ```js import { mount } from 'vue-test-utils' -import Component from './component' +import Composant from './composant' -describe('Component', () => { - test('is a Vue instance', () => { - const wrapper = mount(Component) +describe('Composant', () => { + test('est une instance de Vue', () => { + const wrapper = mount(Composant) expect(wrapper.isVueInstance()).toBeTruthy() }) }) ``` -### Resources +### Ressources -- [Example project for this setup](https://github.com/vuejs/vue-test-utils-jest-example) -- [Examples and slides from Vue Conf 2017](https://github.com/codebryo/vue-testing-with-jest-conf17) +- [Projet exemple pour cette installation](https://github.com/vuejs/vue-test-utils-jest-example) +- [Exemples et diapositives depuis la Vue Conf 2017](https://github.com/codebryo/vue-testing-with-jest-conf17) - [Jest](https://facebook.github.io/jest/) - [Babel preset env](https://github.com/babel/babel-preset-env) diff --git a/docs/en/guides/testing-SFCs-with-mocha-webpack.md b/docs/en/guides/testing-SFCs-with-mocha-webpack.md index f7013a015..72ba7d5ac 100644 --- a/docs/en/guides/testing-SFCs-with-mocha-webpack.md +++ b/docs/en/guides/testing-SFCs-with-mocha-webpack.md @@ -1,22 +1,22 @@ -# Testing Single File Components with Mocha + webpack +# Tester des composants monofichiers avec Mocha + Webpack -> An example project for this setup is available on [GitHub](https://github.com/vuejs/vue-test-utils-mocha-webpack-example). +> Un projet exemple pour cette installation est disponible sur [GitHub](https://github.com/vuejs/vue-test-utils-mocha-webpack-example). -Another strategy for testing SFCs is compiling all our tests via webpack and then run it in a test runner. The advantage of this approach is that it gives us full support for all webpack and `vue-loader` features, so we don't have to make compromises in our source code. +Une des stratégies pour tester des composants monofichiers est de compiler tous nos tests via webpack puis de les passer dans un lanceur de tests. L'avantage de cette approche est qu'elle procure un support complet pour les fonctionnalités de webpack et de `vue-loader`, et ce, afin de ne pas réaliser de compromis dans notre code. -You can technically use any test runner you like and manually wire things together, but we've found [`mocha-webpack`](https://github.com/zinserjan/mocha-webpack) to provide a very streamlined experience for this particular task. +Techniquement, vous pouvez utiliser n'importe quel lanceur de tests et relier le tout manuellement. Cependant, nous avons trouvé [`mocha-webpack`](https://github.com/zinserjan/mocha-webpack) qui procure une expérience très simplifiée pour cette tâche particulière. -## Setting Up `mocha-webpack` +## Mettre en place `mocha-webpack` -We will assume you are starting with a setup that already has webpack, vue-loader and Babel properly configured - e.g. the `webpack-simple` template scaffolded by `vue-cli`. +On va supposer que vous commencez avec une installation qui a déjà webpack, vue-loader et Babel de correctement configurés (cf. le template `webpack-simple` via `vue-cli`). -The first thing to do is installing test dependencies: +La première chose à faire est d'installer les dépendances de tests : ``` bash npm install --save-dev vue-test-utils mocha mocha-webpack ``` -Next we need to define a test script in our `package.json`. +Ensuite, on doit définir un script test dans notre `package.json`. ```json // package.json @@ -27,19 +27,19 @@ Next we need to define a test script in our `package.json`. } ``` -A few things to note here: +Quelques éléments importants à noter : -- The `--webpack-config` flag specifies the webpack config file to use for the tests. In most cases, this would be identical to the config you use for the actual project with one small tweak. We will talk about this later. +- Le paramètre `--webpack-config` indique le fichier de configuration webpack à utiliser pour les tests. Dans la plupart des cas, c'est identique à la configuration du projet actuel avec une petite modification. On en reparlera plus tard. -- The `--require` flag ensures the file `test/setup.js` is run before any tests, in which we can setup the global environment for our tests to be run in. +- Le paramètre `--require` permet de s'assurer que le fichier `test/setup.js` est bien exécuté avant les tests. Dans celui-ci, on met en place l'environnement où nos tests vont être éxécutés. -- The final argument is a glob for the test files to be included in the test bundle. +- Le dernier paramètre est un glob pour indiquer les fichiers de tests à inclure dans le paquet. -### Extra webpack Configuration +### Configuration supplémentaire pour webpack -#### Externalizing NPM Dependencies +#### Externaliser les dépendances NPM -In our tests we will likely import a number of NPM dependencies - some of these modules may be written without browser usage in mind and simply cannot be bundled properly by webpack. Another consideration is externalizing dependencies greatly improves test boot up speed. We can externalize all NPM dependencies with `webpack-node-externals`: +Dans nos tests, nous allons sûrement importer un nombre conséquent de dépendances NPM, certaines d'entre-elles n'ont pas été conçues pour une utilisation dans un navigateur et ne peuvent être empaquetées par webpack. Il faut aussi considérer qu'externaliser les dépendances augmente énormément la vitesse de lancement des tests. On peut externaliser toutes les dépendances NPM avec `webpack-node-externals -externals` : ```js // webpack.config.js @@ -51,9 +51,9 @@ module.exports = { } ``` -#### Source Maps +#### Carte des sources * TODO : PAS SUR ICI * -Source maps need to be inlined to be picked up by `mocha-webpack`. The recommended config is: +La carte des sources doit être indiquée pour être utilisée par `mocha-webpack`. La configuration recommandée est la suivante : ``` js module.exports = { @@ -62,49 +62,49 @@ module.exports = { } ``` -If debugging via IDE, it's also recommended to add the following: +Si vous déboguer via votre IDE, il est recommandé d'ajouter la configuration suivante : ``` js module.exports = { // ... output: { // ... - // use absolute paths in sourcemaps (important for debugging via IDE) + // utiliser des chemins absolus (c'est important si vous déboguez avec un IDE) devtoolModuleFilenameTemplate: '[absolute-resource-path]', devtoolFallbackModuleFilenameTemplate: '[absolute-resource-path]?[hash]' } } ``` -### Setting Up Browser Environment +### Mettre en place l'environnement du navigateur -`vue-test-utils` requires a browser environment to run. We can simulate it in Node.js using `jsdom-global`: +`vue-test-utils` requiert en environnement de navigateur pour fonctionner. On peut le simuler avec Node.js en utilisant `jsdom-global` : ```bash npm install --save-dev jsdom jsdom-global ``` -Then in `test/setup.js`: +Puis dans `test/setup.js`: ``` js require('jsdom-global')() ``` -This adds a browser environment to node, so that `vue-test-utils` can run correctly. +Cela ajoute un environnement de navigateur dans node afin que `vue-test-utils` fonctionne correctement. -### Picking an Assertion Library +### Choisir une bibliothèque d'assertions -[Chai](http://chaijs.com/) is a popular assertion library that is commonly used alongside Mocha. You may also want to check out [Sinon](http://sinonjs.org/) for creating spies and stubs. +[Chai](http://chaijs.com/) est une bibliothèque populaire qui est généralement utilisée avec Mocha. Vous pouvez aussi jeter un coup d'œil à [Sinon](http://sinonjs.org/) pour créer des espions et des fonctions avec un comportement pré-programmé (stubs). -Alternatively you can use `expect` which is now part of Jest, and exposes [the exact same API](http://facebook.github.io/jest/docs/en/expect.html#content) in Jest docs. +Vous pouvez utiliser, alternativement, `expect` qui fait maintenant partie de Jest et expose [la même API](http://facebook.github.io/jest/docs/en/expect.html#content) dans la documentation de Jest. -We will be using `expect` here and make it globally available so that we don't have to import it in every test: +On va utiliser `expect` et le rendre globalement accessible afin de ne pas avoir à l'importer pour chaque test : ``` bash npm install --save-dev expect ``` -Then in `test/setup.js`: +Puis dans `test/setup.js`: ``` js require('jsdom-global')() @@ -112,21 +112,21 @@ require('jsdom-global')() global.expect = require('expect') ``` -### Optimizing Babel for Tests +### Optimiser Babel pour les tests -Notice that we are using `babel-loader` to handle JavaScript. You should already have Babel configured if you are using it in your app via a `.babelrc` file. Here `babel-loader` will automatically use the same config file. +Notez que nous utilisons `babel-loader` pour gérer JavaScript. Vous devriez déjà avoir Babel de configuré si vous l'utilisez dans votre application via un fichier `.babelrc`. Ici `babel-loader` va automatiquement utiliser le même fichier de configuration. -One thing to note is that if you are using Node 6+, which already supports the majority of ES2015 features, you can configure a separate Babel [env option](https://babeljs.io/docs/usage/babelrc/#env-option) that only transpiles features that are not already supported in the Node version you are using (e.g. `stage-2` or flow syntax support, etc.) +Une autre chose à noter est que si vous utilisez une version de Node >= 6, qui supporte déjà une majorité des fonctionnalités d'ES2015, vous pouvez configurer séparément un autre Babel [env option](https://babeljs.io/docs/usage/babelrc/#env-option) qui va uniquement transpiler les fonctionnalités non supportées dans la version de Node que vous utilisez (c.à.d `stage-2` ou le support de la syntaxe flow, etc.). -### Adding a test +### Ajouter un test -Create a file in `src` named `Counter.vue`: +Créez dans le dossier `src` un fichier nommé `Compteur.vue`: ``` html @@ -134,45 +134,45 @@ Create a file in `src` named `Counter.vue`: export default { data () { return { - count: 0 + compteur: 0 } }, methods: { - increment () { - this.count++ + incrementer () { + this.compteur++ } } } ``` -And create a test file named `test/Counter.spec.js` with the following code: +Puis créez un test nommé `test/Compteur.spec.js` avec le code suivant : ```js import { shallow } from 'vue-test-utils' -import Counter from '../src/Counter.vue' +import Compteur from '../src/Compteur.vue' -describe('Counter.vue', () => { - it('increments count when button is clicked', () => { - const wrapper = shallow(Counter) +describe('Compteur.vue', () => { + it('incrémente le compteur quand le bouton est cliqué', () => { + const wrapper = shallow(Compteur) wrapper.find('button').trigger('click') expect(wrapper.find('div').text()).toMatch('1') }) }) ``` -And now we can run the test: +Et maintenant on peut lancer le test avec : ``` npm run unit ``` -Woohoo, we got our tests running! +Woohoo, nos tests fonctionnent ! -### Resources +### Ressources -- [Example project for this setup](https://github.com/vuejs/vue-test-utils-mocha-webpack-example) +- [Projet exemple pour cette installation](https://github.com/vuejs/vue-test-utils-mocha-webpack-example) - [Mocha](https://mochajs.org/) - [mocha-webpack](http://zinserjan.github.io/mocha-webpack/) - [Chai](http://chaijs.com/) diff --git a/docs/en/guides/using-with-vue-router.md b/docs/en/guides/using-with-vue-router.md index d69353af0..c772d91b7 100644 --- a/docs/en/guides/using-with-vue-router.md +++ b/docs/en/guides/using-with-vue-router.md @@ -1,10 +1,10 @@ -# Using with Vue Router +# Utilisation avec Vue Router -## Installing Vue Router in tests +## Installer Vue Router pour nos tests -You should never install Vue Router on the Vue base constructor in tests. Installing Vue Router adds `$route` and `$router` as read-only properties on Vue prototype. +Vous ne devez jamais installer Vue Router sur le constructeur de base de Vue pour vos tests. Installer Vue Router de cette manière ajoute `$route` et `$router` en tant que propriétés en lecture seule sur le prototype Vue. -To avoid this, we can create a localVue, and install Vue Router on that. +Pour éviter cela, on peut utiliser une localVue, et installer Vue Router dessus. ```js import VueRouter from 'vue-router' @@ -17,13 +17,13 @@ shallow(Component, { }) ``` -## Testing components that use `router-link` or `router-view` +## Tester des composants qui utilisent `router-link` ou `router-view` -When you install Vue Router, the `router-link` and `router-view` components are registered. This means we can use them anywhere in our application without needing to import them. +Quand vous installez Vue Router, les composants `router-link` et `router-view` sont enregistrés. Cela veut dire que l'on peut les utiliser n'importe où dans notre application sans avoir besoin de les importer. -When we run tests, we need to make these vue-router components available to the component we're mounting. There are two methods to do this. +On doit donc rendre ces composants vue-router disponibles au composant que nous testons. Il y a deux méthodes pour cela. -### Using stubs +### Utiliser des stubs ```js shallow(Component, { @@ -31,7 +31,7 @@ shallow(Component, { }) ``` -### Installing Vue Router with localVue +### Installer Vue Router avec localVue ```js import VueRouter from 'vue-router' @@ -44,13 +44,13 @@ shallow(Component, { }) ``` -## Mocking `$route` and `$router` +## Simuler `$route` and `$router` -Sometimes you want to test that a component does something with parameters from the `$route` and `$router` objects. To do that, you can pass custom mocks to the Vue instance. +Quelques fois, vous souhaitez tester qu'un composant réagisse correctement avec les paramètres des objets `$route` et `$router`. Pour cela, vous pouvez passer des imitations à l'instance de Vue. ```js const $route = { - path: '/some/path' + path: '/un/super/chemin' } const wrapper = shallow(Component, { @@ -59,13 +59,13 @@ const wrapper = shallow(Component, { } }) -wrapper.vm.$router // /some/path +wrapper.vm.$router // /un/super/chemin ``` -## Common gotchas +## Trucs et astuces -Installing Vue Router adds `$route` and `$router` as read-only properties on Vue prototype. +Installer Vue Router ajoute `$route` et `$router` en tant que propriétés en lecture seule au prototype de Vue. -This means any future tests that try to mock `$route` or `$router` will fail. +Cela veut dire que n'importe quel futur test qui va essayer de modifier `$route` ou `$router` va échouer. -To avoid this, never install Vue Router when you're running tests. +Pour éviter cela, n'installez jamais Vue Router quand vous lancez vos tests. diff --git a/docs/en/guides/using-with-vuex.md b/docs/en/guides/using-with-vuex.md index 85f40d7fd..f73a6fe49 100644 --- a/docs/en/guides/using-with-vuex.md +++ b/docs/en/guides/using-with-vuex.md @@ -1,17 +1,17 @@ -# Using with Vuex +# Utiliser avec Vuex -In this guide, we'll see how to test Vuex in components with `vue-test-utils`. +Dans ce guide, nous allons voir comment tester Vuex dans des composants grâce à `vue-test-utils`. -## Mocking Actions +## Simuler des Actions -Let’s look at some code. +Regardons un peu de code ! -This is the component we want to test. It calls Vuex actions. +Ci-dessous, le composant que nous voulons tester. Il fait appel à des actions Vuex. ``` html @@ -24,7 +24,7 @@ export default{ ...mapActions([ 'actionClick' ]), - actionInputIfTrue: function actionInputIfTrue (event) { + lanceActionInputSiVrai: function lanceActionInputSiVrai (event) { const inputValue = event.target.value if (inputValue === 'input') { this.$store.dispatch('actionInput', { inputValue }) @@ -35,13 +35,13 @@ export default{ ``` -For the purposes of this test, we don’t care what the actions do, or what the store looks like. We just need to know that these actions are being fired when they should, and that they are fired with the expected value. +Pour les objectifs de ce test, on se fiche de ce que les actions font, ou à ce quoi le store ressemble. On doit juste savoir si ces actions sont lancées lorsqu'elles sont supposées l'être, et ce, avec les valeurs attendues. -To test this, we need to pass a mock store to Vue when we shallow our component. +Pour tester cela, on doit passer un store fictif à Vue lorsque l'on isole notre composant. *TODO : Isoler, bon verbe ?* -Instead of passing the store to the base Vue constructor, we can pass it to a - [localVue](../api/options.md#localvue). A localVue is a scoped Vue constructor that we can make changes to without affecting the global Vue constructor. +Au lieu de passer le store au constructeur de base de Vue, on peut le passer à - [localVue](../api/options.md#localvue). Une localVue est un constructeur à portée limitée de Vue sur lequel on peut effectuer des changements sans avoir à affecter le constructeur global. -Let’s see what this looks like: +Voyons à quoi cela ressemble : ``` js import { shallow, createLocalVue } from 'vue-test-utils' @@ -67,7 +67,7 @@ describe('Actions.vue', () => { }) }) - it('calls store action actionInput when input value is input and an input event is fired', () => { + it('appelle une action du store (actionInput) quand la valeur de l\'input est input et qu\'un évènement input est lancée', () => { const wrapper = shallow(Actions, { store, localVue }) const input = wrapper.find('input') input.element.value = 'input' @@ -75,7 +75,7 @@ describe('Actions.vue', () => { expect(actions.actionInput).toHaveBeenCalled() }) - it('does not call store action actionInput when input value is not input and an input event is fired', () => { + it('n\'appelle pas l\'action du store actionInput quand la valeur de l\'input n\'est pas input et qu\'un évènement input est lancée', () => { const wrapper = shallow(Actions, { store, localVue }) const input = wrapper.find('input') input.element.value = 'not input' @@ -83,7 +83,7 @@ describe('Actions.vue', () => { expect(actions.actionInput).not.toHaveBeenCalled() }) - it('calls store action actionClick when button is clicked', () => { + it('appelle l\'action du store actionClick quand le bouton est cliqué', () => { const wrapper = shallow(Actions, { store, localVue }) wrapper.find('button').trigger('click') expect(actions.actionClick).toHaveBeenCalled() @@ -91,23 +91,23 @@ describe('Actions.vue', () => { }) ``` -What’s happening here? First we tell Vue to use Vuex with the `Vue.use` method. This is just a wrapper around `Vue.use`. +Que se passe-t-il ici ? Premièrement, on indique à Vue d'utiliser Vuex avec la méthode `use`. C'est tout simplement une surcouche de `Vue.use`. -We then make a mock store by calling new `Vuex.store` with our mock values. We only pass it the actions, since that’s all we care about. +On va ensuite créer un store fictif en appelant `new Vuex.Store` avec nos propres valeurs. À noté que l'on indique uniquement nos actions, car on ne s'intéresse qu'à elles. -The actions are [jest mock functions](https://facebook.github.io/jest/docs/en/mock-functions.html). These mock functions give us methods to assert whether the actions were called or not. +Les actions sont des [fonctions de simulations de Jest](https://facebook.github.io/jest/docs/en/mock-functions.html). Ces fonctions nous donnent accès à des méthodes afin de réaliser des assertions si l'action à été appelée ou non. -We can then assert in our tests that the action stub was called when expected. +On peut ensuite s'assurer dans nos tests que les actions ont été appelées au bon moment. -Now the way we define the store might look a bit foreign to you. +La manière dont on définit le store peut vous paraître un peu étrange. -We’re using `beforeEach` to ensure we have a clean store before each test. `beforeEach` is a mocha hook that’s called before each test. In our test, we are reassigning the store variables value. If we didn’t do this, the mock functions would need to be automatically reset. It also lets us change the state in our tests, without it affecting later tests. +On utilise `beforeEach` pour s'assurer que nous avons un store propre avant chaque test. `beforeEach` est un hook de Mocha qui est appelé avant chaque test. Dans nos tests, on réassigne des valeurs aux variables du store. Si on ne le fait pas, les fonctions de simulations auraient besoin d'être automatiquement réinitialisées. Cela nous laisse la possibilité de changer le state dans nos tests, sans avoir à affecter les prochains. -The most important thing to note in this test is that **we create a mock Vuex store and then pass it to vue-test-utils**. +La chose la plus importante à noter dans ce test est que **l'on créer une simulation d'un store Vuex, qui est ensuite passer à vue-test-utils**. -Great, so now we can mock actions, let’s look at mocking getters. +Génial, on peut désormais simuler des actions. Allons avoir comment simuler des getters ! -## Mocking Getters +## Simuler des Getters ``` html @@ -130,9 +130,9 @@ export default{ ``` -This is a fairly simple component. It renders the result of the getters `clicks` and `inputValue`. Again, we don’t really care about what those getters returns – just that the result of them is being rendered correctly. +C'est un composant relativement simple. Il affiche le résultat des getters `clicks` et `inputValue`. Encore une fois, on se fiche de savoir ce que ces getters retournent. On souhaite juste savoir si les résultats sont affichés correctement. -Let’s see the test: +Jetons un œil à un test : ``` js import { shallow, createLocalVue } from 'vue-test-utils' @@ -158,28 +158,28 @@ describe('Getters.vue', () => { }) }) - it('Renders state.inputValue in first p tag', () => { + it('affiche state.inputValue dans le premier tag p', () => { const wrapper = shallow(Actions, { store, localVue }) const p = wrapper.find('p') expect(p.text()).toBe(getters.inputValue()) }) - it('Renders state.clicks in second p tag', () => { + it('affiche stat.clicks dans le second tag p', () => { const wrapper = shallow(Actions, { store, localVue }) const p = wrapper.findAll('p').at(1) expect(p.text()).toBe(getters.clicks().toString()) }) }) ``` -This test is similar to our actions test. We create a mock store before each test, pass it as an option when we call `shallow`, and assert that the value returned by our mock getters is being rendered. +Ce test est similaire à notre test sur les actions. On créer un store fictif avant chaque test, on le passe ensuite comme une option lorsque l'on appele `shallow`. Pour finir, on asserte que la valeur retournée par nos getters fictifs est bien affichée. -This is great, but what if we want to check our getters are returning the correct part of our state? +C'est génial, mais comment faisons nous pour vérifier que nos getters retournent correctement les parties du state ? -## Mocking with Modules +## Simulation avec des Modules -[Modules](https://vuex.vuejs.org/en/modules.html) are useful for separating out our store into manageable chunks. They also export getters. We can use these in our tests. +[Modules](https://vuex.vuejs.org/en/modules.html) sont utiles pour séparer un store en plusieurs morceaux. Ils exportent des getters que l'on peut utiliser dans nos tests. -Let’s look at our component: +Jetons un œil à ce composant : ``` html