From b785a44275edb9bb0aac81093676487d5078cd45 Mon Sep 17 00:00:00 2001
From: Bruno Lesieur <bruno.lesieur@gmail.com>
Date: Sat, 1 Jul 2017 10:41:10 +0200
Subject: [PATCH 1/3] Traduction de unit-testing.md

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>
---
 src/v2/guide/unit-testing.md | 76 ++++++++++++++++++------------------
 1 file changed, 38 insertions(+), 38 deletions(-)

diff --git a/src/v2/guide/unit-testing.md b/src/v2/guide/unit-testing.md
index 0128b43115..ed92b895f5 100644
--- a/src/v2/guide/unit-testing.md
+++ b/src/v2/guide/unit-testing.md
@@ -1,16 +1,16 @@
 ---
-title: Unit Testing (En)
+title: Tests unitaires
 type: guide
 order: 23
 ---
 
-## Setup and Tooling
+## Outils et mise en place
 
-<p class="tip">**Cette page est en cours de traduction française. Revenez une autre fois pour lire une traduction achevée ou [participez à la traduction française ici](https://github.com/vuejs-fr/vuejs.org).**</p><p>Anything compatible with a module-based build system will work, but if you're looking for a specific recommendation, try the [Karma](http://karma-runner.github.io) test runner. It has a lot of community plugins, including support for [webpack](https://github.com/webpack/karma-webpack) and [Browserify](https://github.com/Nikku/karma-browserify). For detailed setup, please refer to each project's respective documentation, though these example Karma configurations for [webpack](https://github.com/vuejs-templates/webpack/blob/master/template/test/unit/karma.conf.js) and [Browserify](https://github.com/vuejs-templates/browserify/blob/master/template/karma.conf.js) may help you get started.</p>
+N'importe quoi de compatible avec un module basé sur un système de build va fonctionner. Mais si vous hésitez sur le choix d'un outil en particulier, essayez le lanceur de tests [Karma](http://karma-runner.github.io). Il y a beaucoup de plugins communautaires, incluant le support de [webpack](https://github.com/webpack/karma-webpack) et [Browserify](https://github.com/Nikku/karma-browserify). Pour une mise en place détaillée, référez-vous à la documentation respective de chaque projet. Ces exemples de configuration de Karma pour [webpack](https://github.com/vuejs-templates/webpack/blob/master/template/test/unit/karma.conf.js) et [Browserify](https://github.com/vuejs-templates/browserify/blob/master/template/karma.conf.js) pourront vous aider à démarrer.
 
-## Simple Assertions
+## De simples assertions
 
-In terms of code structure for testing, you don't have to do anything special in your components to make them testable. Just export the raw options:
+En terme de structure de test de code, vous n'avez rien de spécial à faire dans vos composants pour les rendre testables. Exportez simplement son objet d'options :
 
 ``` html
 <template>
@@ -21,57 +21,57 @@ In terms of code structure for testing, you don't have to do anything special in
   export default {
     data () {
       return {
-        message: 'hello!'
+        message: 'bonjour !'
       }
     },
     created () {
-      this.message = 'bye!'
+      this.message = 'au revoir !'
     }
   }
 </script>
 ```
 
-When you test that component, all you have to do is import the object along with Vue to make many common assertions:
+Quand vous testez ce composant, tout ce que vous avez à faire est d'importer l'objet d'options avec un objet Vue pour faire des assertions communes :
 
 ``` js
-// Import Vue and the component being tested
+// Importer Vue et le composant à tester
 import Vue from 'vue'
 import MyComponent from 'path/to/MyComponent.vue'
 
-// Here are some Jasmine 2.0 tests, though you can
-// use any test runner / assertion library combo you prefer
+// Ici nous avons plusieurs tests avec Jasmine 2.0, cependant vous pouvez utiliser
+// n'importe quel combo de lanceur de tests / bibliothèque d'assertions que vous préférez
 describe('MyComponent', () => {
-  // Inspect the raw component options
-  it('has a created hook', () => {
+  // Inspecter l'objet d'options du composant
+  it('a le hook `created`', () => {
     expect(typeof MyComponent.created).toBe('function')
   })
 
-  // Evaluate the results of functions in
-  // the raw component options
-  it('sets the correct default data', () => {
+  // Évaluer les résultats des fonctions dans
+  // l'objet d'options du composant
+  it('contient les données par défaut', () => {
     expect(typeof MyComponent.data).toBe('function')
     const defaultData = MyComponent.data()
-    expect(defaultData.message).toBe('hello!')
+    expect(defaultData.message).toBe('bonjour !')
   })
 
-  // Inspect the component instance on mount
-  it('correctly sets the message when created', () => {
+  // Inspecter l'instance au montage du composant
+  it('affecte correctement les messages à la création', () => {
     const vm = new Vue(MyComponent).$mount()
-    expect(vm.message).toBe('bye!')
+    expect(vm.message).toBe('au revoir !')
   })
 
-  // Mount an instance and inspect the render output
-  it('renders the correct message', () => {
+  // Monter une instance et inspecter le résultat en sortie
+  it('rend le message correcte', () => {
     const Ctor = Vue.extend(MyComponent)
     const vm = new Ctor().$mount()
-    expect(vm.$el.textContent).toBe('bye!')
+    expect(vm.$el.textContent).toBe('au revoir !')
   })
 })
 ```
 
-## Writing Testable Components
+## Écrire des composants testables
 
-A lot of component's render output are primarily determined by the props they receive. In fact, if a component's render output solely depends on its props, it becomes quite straightforward to test, similar to asserting the return value of a pure function with different arguments. Take a contrived example:
+Beaucoup de sortie de rendu de composants sont principalement déterminées selon les props que les composants reçoivent. En fait, si une sortie de rendu de composant dépend uniquement de ses props, il devient très rapide de le tester. Exactement de la même manière qu'on ferrait des assertions sur la valeur de retour d'une fonction standard avec différents arguments. Voici un exemple :
 
 ``` html
 <template>
@@ -85,13 +85,13 @@ A lot of component's render output are primarily determined by the props they re
 </script>
 ```
 
-You can assert its render output with different props using the `propsData` option:
+Vous pouvez faire des assertions sur le rendu en sortie avec différentes props en utilisant l'option `propsData` :
 
 ``` js
 import Vue from 'vue'
 import MyComponent from './MyComponent.vue'
 
-// helper function that mounts and returns the rendered text
+// Fonction utilitaire qui monte et retourne le texte rendu
 function getRenderedText (Component, propsData) {
   const Ctor = Vue.extend(Component)
   const vm = new Ctor({ propsData: propsData }).$mount()
@@ -99,29 +99,29 @@ function getRenderedText (Component, propsData) {
 }
 
 describe('MyComponent', () => {
-  it('renders correctly with different props', () => {
+  it('rendre correctement le message avec différentes props', () => {
     expect(getRenderedText(MyComponent, {
-      msg: 'Hello'
-    })).toBe('Hello')
+      msg: 'Bonjour'
+    })).toBe('Bonjour')
 
     expect(getRenderedText(MyComponent, {
-      msg: 'Bye'
-    })).toBe('Bye')
+      msg: 'Au revoir'
+    })).toBe('Au revoir')
   })
 })
 ```
 
-## Asserting Asynchronous Updates
+## Assertions de mise à jour asynchrones
 
-Since Vue [performs DOM updates asynchronously](reactivity.html#Async-Update-Queue), assertions on DOM updates resulting from state change will have to be made in a `Vue.nextTick` callback:
+Parce que Vue [fait les mises à jour du DOM de manière asynchrone](reactivity.html#File-d’attente-de-mise-a-jour-asynchrone), les assertions sur les mises à jour du DOM dû à un changement d'état doivent être faites dans une fonction de rappel `Vue.nextTick` :
 
 ``` js
-// Inspect the generated HTML after a state update
-it('updates the rendered message when vm.message updates', done => {
+// Inspecter le HTML généré après une mise à jour d'état
+it('mettre à jour le message rendu quand `vm.message` est mis à jour', done => {
   const vm = new Vue(MyComponent).$mount()
   vm.message = 'foo'
 
-  // wait a "tick" after state change before asserting DOM updates
+  // attendre une boucle (« tick ») après le changement d'état avant de faire l'assertion des mises à jour du DOM
   Vue.nextTick(() => {
     expect(vm.$el.textContent).toBe('foo')
     done()
@@ -129,4 +129,4 @@ it('updates the rendered message when vm.message updates', done => {
 })
 ```
 
-We are planning to work on a collection of common test helpers that makes it even simpler to render components with different constraints (e.g. shallow rendering that ignores child components) and assert their output.
+Nous avons planifié de travailler sur une collection de fonctions utilitaires de tests communs pour rendre encore plus simple les tests de composant de rendu avec différentes contraintes (par ex. des rendus peu profonds ignorant les composants enfants) et faire des assertions de leur sortie.

From 9432dc63ff030f7c4e48f7eae908c67fc8e57120 Mon Sep 17 00:00:00 2001
From: Bruno Lesieur <bruno.lesieur@gmail.com>
Date: Thu, 6 Jul 2017 09:41:29 +0200
Subject: [PATCH 2/3] Review de Sylvain

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>
---
 src/v2/guide/unit-testing.md | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/v2/guide/unit-testing.md b/src/v2/guide/unit-testing.md
index ed92b895f5..9e0624f144 100644
--- a/src/v2/guide/unit-testing.md
+++ b/src/v2/guide/unit-testing.md
@@ -6,11 +6,11 @@ order: 23
 
 ## Outils et mise en place
 
-N'importe quoi de compatible avec un module basé sur un système de build va fonctionner. Mais si vous hésitez sur le choix d'un outil en particulier, essayez le lanceur de tests [Karma](http://karma-runner.github.io). Il y a beaucoup de plugins communautaires, incluant le support de [webpack](https://github.com/webpack/karma-webpack) et [Browserify](https://github.com/Nikku/karma-browserify). Pour une mise en place détaillée, référez-vous à la documentation respective de chaque projet. Ces exemples de configuration de Karma pour [webpack](https://github.com/vuejs-templates/webpack/blob/master/template/test/unit/karma.conf.js) et [Browserify](https://github.com/vuejs-templates/browserify/blob/master/template/karma.conf.js) pourront vous aider à démarrer.
+N'importe quoi de compatible avec un module basé sur un système de build basé sur les modules va fonctionner. Mais si vous cherchez une recommandation particulière, essayez le lanceur de tests [Karma](http://karma-runner.github.io). Il y a beaucoup de plugins communautaires, incluant le support de [webpack](https://github.com/webpack/karma-webpack) et [Browserify](https://github.com/Nikku/karma-browserify). Pour une mise en place détaillée, référez-vous à la documentation respective de chaque projet. Ces exemples de configuration de Karma pour [webpack](https://github.com/vuejs-templates/webpack/blob/master/template/test/unit/karma.conf.js) et [Browserify](https://github.com/vuejs-templates/browserify/blob/master/template/karma.conf.js) pourront vous aider à démarrer.
 
-## De simples assertions
+## Des assertions simples
 
-En terme de structure de test de code, vous n'avez rien de spécial à faire dans vos composants pour les rendre testables. Exportez simplement son objet d'options :
+En termes de structure de code pour les tests, vous n'avez rien de spécial à faire dans vos composants pour les rendre testables. Exportez juste les options en l'état :
 
 ``` html
 <template>
@@ -31,7 +31,7 @@ En terme de structure de test de code, vous n'avez rien de spécial à faire dan
 </script>
 ```
 
-Quand vous testez ce composant, tout ce que vous avez à faire est d'importer l'objet d'options avec un objet Vue pour faire des assertions communes :
+Quand vous testez ce composant, tout ce que vous avez à faire est d'importer l'objet d'options aux côtés de Vue pour faire une série d'assertions communes :
 
 ``` js
 // Importer Vue et le composant à tester
@@ -71,7 +71,7 @@ describe('MyComponent', () => {
 
 ## Écrire des composants testables
 
-Beaucoup de sortie de rendu de composants sont principalement déterminées selon les props que les composants reçoivent. En fait, si une sortie de rendu de composant dépend uniquement de ses props, il devient très rapide de le tester. Exactement de la même manière qu'on ferrait des assertions sur la valeur de retour d'une fonction standard avec différents arguments. Voici un exemple :
+Une bonne partie du code en sortie du rendu d'un composant est principalement déterminé par les props qu'ils reçoivent. En fait, si le rendu d'un composant dépend uniquement de ses props, il devient assez facile à tester, de la même manière que l'on ferait une assertion sur la valeur de retour d'une fonction pure avec différents arguments. Voici un exemple :
 
 ``` html
 <template>
@@ -99,7 +99,7 @@ function getRenderedText (Component, propsData) {
 }
 
 describe('MyComponent', () => {
-  it('rendre correctement le message avec différentes props', () => {
+  it('donne un rendu correct avec différentes props', () => {
     expect(getRenderedText(MyComponent, {
       msg: 'Bonjour'
     })).toBe('Bonjour')
@@ -111,13 +111,13 @@ describe('MyComponent', () => {
 })
 ```
 
-## Assertions de mise à jour asynchrones
+## Assertions sur des mises à jour asynchrones
 
-Parce que Vue [fait les mises à jour du DOM de manière asynchrone](reactivity.html#File-d’attente-de-mise-a-jour-asynchrone), les assertions sur les mises à jour du DOM dû à un changement d'état doivent être faites dans une fonction de rappel `Vue.nextTick` :
+Parce que Vue [fait les mises à jour du DOM de manière asynchrone](reactivity.html#File-d’attente-de-mise-a-jour-asynchrone), les assertions sur les mises à jour du DOM résultant d'un changement d'état doivent être faites dans une fonction de rappel `Vue.nextTick` :
 
 ``` js
 // Inspecter le HTML généré après une mise à jour d'état
-it('mettre à jour le message rendu quand `vm.message` est mis à jour', done => {
+it('met à jour le message rendu quand `vm.message` est mis à jour', done => {
   const vm = new Vue(MyComponent).$mount()
   vm.message = 'foo'
 
@@ -129,4 +129,4 @@ it('mettre à jour le message rendu quand `vm.message` est mis à jour', done =>
 })
 ```
 
-Nous avons planifié de travailler sur une collection de fonctions utilitaires de tests communs pour rendre encore plus simple les tests de composant de rendu avec différentes contraintes (par ex. des rendus peu profonds ignorant les composants enfants) et faire des assertions de leur sortie.
+Nous prévoyons de travailler sur une collection de fonctions utilitaires de tests communs pour rendre encore plus simple le rendu de composants avec différentes contraintes (par ex. des rendus peu profonds ignorant les composants enfants) et faire des assertions sur le code en sortie.

From 8393b887a4f7ca7f2ad03ecc38033e88779f1b07 Mon Sep 17 00:00:00 2001
From: Bruno Lesieur <bruno.lesieur@gmail.com>
Date: Tue, 11 Jul 2017 13:15:07 +0200
Subject: [PATCH 3/3] Review de Forresst et Sylvain

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>
---
 src/v2/guide/unit-testing.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/v2/guide/unit-testing.md b/src/v2/guide/unit-testing.md
index 9e0624f144..5b79def98c 100644
--- a/src/v2/guide/unit-testing.md
+++ b/src/v2/guide/unit-testing.md
@@ -6,7 +6,7 @@ order: 23
 
 ## Outils et mise en place
 
-N'importe quoi de compatible avec un module basé sur un système de build basé sur les modules va fonctionner. Mais si vous cherchez une recommandation particulière, essayez le lanceur de tests [Karma](http://karma-runner.github.io). Il y a beaucoup de plugins communautaires, incluant le support de [webpack](https://github.com/webpack/karma-webpack) et [Browserify](https://github.com/Nikku/karma-browserify). Pour une mise en place détaillée, référez-vous à la documentation respective de chaque projet. Ces exemples de configuration de Karma pour [webpack](https://github.com/vuejs-templates/webpack/blob/master/template/test/unit/karma.conf.js) et [Browserify](https://github.com/vuejs-templates/browserify/blob/master/template/karma.conf.js) pourront vous aider à démarrer.
+Tout ce qui est compatible avec un système de build basé sur des modules fonctionnera. Mais si vous cherchez une recommandation particulière, essayez le lanceur de tests [Karma](http://karma-runner.github.io). Il y a beaucoup de plugins communautaires, incluant le support de [webpack](https://github.com/webpack/karma-webpack) et [Browserify](https://github.com/Nikku/karma-browserify). Pour une mise en place détaillée, référez-vous à la documentation respective de chaque projet. Ces exemples de configuration de Karma pour [webpack](https://github.com/vuejs-templates/webpack/blob/master/template/test/unit/karma.conf.js) et [Browserify](https://github.com/vuejs-templates/browserify/blob/master/template/karma.conf.js) pourront vous aider à démarrer.
 
 ## Des assertions simples
 
@@ -61,7 +61,7 @@ describe('MyComponent', () => {
   })
 
   // Monter une instance et inspecter le résultat en sortie
-  it('rend le message correcte', () => {
+  it('rend le message correct', () => {
     const Ctor = Vue.extend(MyComponent)
     const vm = new Ctor().$mount()
     expect(vm.$el.textContent).toBe('au revoir !')
@@ -71,7 +71,7 @@ describe('MyComponent', () => {
 
 ## Écrire des composants testables
 
-Une bonne partie du code en sortie du rendu d'un composant est principalement déterminé par les props qu'ils reçoivent. En fait, si le rendu d'un composant dépend uniquement de ses props, il devient assez facile à tester, de la même manière que l'on ferait une assertion sur la valeur de retour d'une fonction pure avec différents arguments. Voici un exemple :
+Une bonne partie du code en sortie du rendu d'un composant est principalement déterminée par les props qu'il reçoit. En fait, si le rendu d'un composant dépend uniquement de ses props, il devient assez facile à tester, de la même manière que l'on ferait une assertion sur la valeur de retour d'une fonction pure avec différents arguments. Voici un exemple :
 
 ``` html
 <template>