Guide: common-tips.md

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)

docs/en/guides/common-tips.md

@@ -1,117 +1,116 @@
-# 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 })
 
 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.