diff --git a/public/docs/ts/latest/guide/testing.jade b/public/docs/ts/latest/guide/testing.jade
index 4859c955..7876a51b 100644
--- a/public/docs/ts/latest/guide/testing.jade
+++ b/public/docs/ts/latest/guide/testing.jade
@@ -1,72 +1,126 @@
 :marked
   We write **unit tests** to explore and confirm the **behavior** of parts of our application.
 
+  Nous écrivons des **tests unitaires** pour explorer et confirmer le **comportement** des différentes parties de notre application.
+
   1. They **guard** against breaking existing code (“regressions”) when we make changes.
+  1. Ils **préviennent** l'apparition de problèmes dans le code existant (“regressions”) quand nous faisons des changements.
+
   1. They **clarify** what  the code does both when used as intended and when faced with deviant conditions.
+  1. Ils **clarifient** ce que le code doit faire, à la fois quand il est utilisé comme attendu et quand il est face à des conditions anormales.
+
   1. They **reveal** mistakes in design and implementation. Tests force us to look at our code from many angles. When a part of our application seems hard to test, we may have discovered a design flaw, something we can cure now rather than later when it becomes expensive to fix.
+  1. Ils **révèlent** les erreurs dans le design et l'implémentation. Les tests nous forcent à regarder notre code depuis plusieurs angles. Quand une partie de l'application semble difficile à tester, c'est que nous venons peut-être de découvrir un problème de design, quelque chose que nous pourrions réparer maintenant plutôt que plus tard quand cela sera couteux.   
     
+
 a(id="top")
 :marked
   # Table of Contents
 
+  # Sommaire
+
   1. [Jasmine Testing 101](#jasmine-101)
+  1. [Débuter avec les tests Jasmine](#jasmine-101)
     - setup to run Jasmine tests in the browser
+    - préparations pour l'éxécution de tests Jasmine dans le navigateur
     - basic Jasmine testing skills
+    - compétences de bases pour les tests avec Jasmine
     - write simple Jasmine tests in TypeScript
+    - écrire un test Jasmine simple avec TypeScript
     - debug a test in the browser
+    - débugger un test dans le navigateur
   
   1. [The Application Under Test](#aut)
-  
+  1. [L'application testée](#aut)
+
   1. [First app test](#first-app-tests)
+  1. [Première application de test](#first-app-tests)
     - test a simple application interface outside of Angular
+    - tester une simple interface d'application à l'éxtérieur d'Angular
     - where to put the test file
+    - où mettre les fichiers tests
     - load a test file with systemJS
+    - charger un fichier test avec system.js
   
   1. [Pipe driven development](#pipe-testing)
+  1. [--Une idée ?--](#pipe-testing)
     - create a test before creating a class
+    - créer un test avant de créer une classe
     - load multiple test files in our test harness, using system.js
+    - charger plusieurs fichiers test dans notre harnais de test, en utilisant system.js 
     - add the Angular 2 library to our test harness
+    - ajouter la librairie Angular 2 à notre harnais
     - watch the new test fail, and fix it
+    - regarder les nouveaux tests échouer, et les réparer
   
   1. Test an Asynchronous Service (forthcoming)
+  1. Tester un service Asynchrone (à venir)
     - test an asynchronous service class outside of Angular
+    - tester une classe représentant un service asynchrone en dehors d'Angular
     - write a test plan in code
+    - écire un plan de test dans le code
     - fake a dependency
+    - simuler une dépendance
     - master the `catch(fail).then(done)` pattern
+    - maitriser le `catch(fail).then(done)` pattern
     - move setup to `beforeEach`
+    - déplacer les préparatifs dans `beforeEach` 
     - test when a dependency fails
+    - tester quand une dépandance échoue
     - control async test timeout
+    - controler et tester les timeout des opérations asynchrones 
   
   1. The Angular Test Environment (forthcoming)
+  1. L'environement de test d' Angular (à venir)
     - the Angular test environment and why we need help
+    - l'environement de test Angular et pourquoi nous en avons besoin
     - add the Angular Test libraries to the  test harness
+    - ajouter la librairie de test Angular au harnais de test
     - test the same async service using Angular Dependency Injection
+    - tester le même service asynchrone en utilisant l'injection de dépendance d'Angular
     - reduce friction with test helpers
+    - réduire la friction avec les utilitaires de test
     - introducing spies
+    - présentation des espions
   
   1. Test a Component (forthcoming)
-     - test the component outside of Angular
+  1. Tester un composant (à venir)
+    - test the component outside of Angular
+    - tester le composant en dehors d'Angular
     - mock the dependent asynchronous service
+    - mocker le service asynchrone dépendant
     - simulate interaction with the view (no DOM)
+    - simuler une interaction avec la vue (sans le DOM)
     - use a spy-promise to control asynchronous test flow
+    - utiliser une promesse espion pour controler le flot de test asynchrone
   
   1. Test a Component in the DOM (forthcoming
+  1. Tester un composant dans le DOM (à venir)
     - test the component inside the Angular test environment
+    - tester un composant dans l'environement de test Angular
     - use the `TestComponentBuilder`
+    - utiliser le `TestComponentBuilder`
     - more test helpers
+    - plus d'utilitaires de tests
     - interact with the DOM
+    - intéragir avec le DOM
     - bind to a mock dependent asynchronous service
+    - liaisons à un mock de service asynchrone dépendant
   
   1. Run the tests with karma (forthcoming)
+  1. Exécuter les test avec karma (à venir)
 
   It’s a big agenda. Fortunately, you can learn a little bit at a time and put each lesson to use.
+  C'est un gros agenda. Heureusement, vous pouvez apprendre petit à petit et mettre chaque leçon en pratique.
 
 a(href="#top").to-top Back to top
+a(href="#top").to-top Revenir en haut
 
 .l-hr
 a(id="jasmine-101")
 :marked
   # Jasmine Testing 101
+  # Débuter avec les tests Jasmine
 != partial("../testing/jasmine-testing-101")
 a(href="#top").to-top Back to top
 
@@ -74,6 +128,7 @@ a(href="#top").to-top Back to top
 a(id="aut")
 :marked
   # The Application to Test
+  # L'application testée
 != partial("../testing/application-under-test")
 a(href="#top").to-top Back to top
 
@@ -81,6 +136,7 @@ a(href="#top").to-top Back to top
 a(id="first-app-tests")
 :marked
   # First app test
+  # Première application de test
 != partial("../testing/first-app-tests")
 a(href="#top").to-top Back to top
 
@@ -95,3 +151,6 @@ a(href="#top").to-top Back to top
   :marked
     The testing chapter is still under development.
     Please bear with us as we both update and complete it.
+
+    Ce chapitre est encore en dévelopement.
+    Merci de votre patience pandant que nous le mettons à jour et le complétons. 
diff --git a/public/docs/ts/latest/testing/application-under-test.jade b/public/docs/ts/latest/testing/application-under-test.jade
index 530ba4dd..2edff4b6 100644
--- a/public/docs/ts/latest/testing/application-under-test.jade
+++ b/public/docs/ts/latest/testing/application-under-test.jade
@@ -3,8 +3,16 @@ include ../_util-fns
 :marked
   We’ll need an Angular application to test, one as simple as possible while having most of the angular features we want to test.
 
+  Nous avons besoin d'une Application Angular à tester, une application aussi simple que possible tout en ayant la plupart des fonctionnalités Angular que nous voulons tester.
+
   What better app than our own [The Tour of Heroes](../tutorial/toh-pt5.html)? We're already quite familiar with it and it fits our criteria, so let's try to test what we've done there.
   
+  Quelle meilleure application que notre [Tours des Héros](../tutorial/toh-pt5.html)? Nous sommes déja bien familié avec elle et elle correspond à nos critères, alors essayons de tester ce que nous avons fait. 
+
   We might end up modifying it a bit, because it doesn't have everything we want to test, but it's the perfect starting point.
   
+  Il est possible que nous la modifions un peut, car elle n'a pas tout ce que nous voulons tester, mais elle est parfaite pour commencer. 
+
   Create a copy of the Tour of Heroes app so that we can fiddle without fear.
+
+  Créer une copie de notre application Tour des Héros pour que nous puissions la modifier sans peur.
diff --git a/public/docs/ts/latest/testing/first-app-tests.jade b/public/docs/ts/latest/testing/first-app-tests.jade
index 90560ad5..bef2c606 100644
--- a/public/docs/ts/latest/testing/first-app-tests.jade
+++ b/public/docs/ts/latest/testing/first-app-tests.jade
@@ -2,59 +2,100 @@ include ../_util-fns
 
 :marked
   In this chapter we'll setup the environment for testing our sample application and write a few easy Jasmine tests of the app's simplest parts.
+  
+  Dans ce chapitre, nous allons configurer l'environement pour tester notre application d'exemple et pour écrire les quelques tests Jasmine des parties les plus simples de l'application.
+
   We'll learn:
+
+  Nous allons apprendre:
+
   - to test one of our application files
+  - à tester un de nos fichiers de l'application
   - why we prefer our test files to be next to their corresponding source files
+  - pourquoi nous préférons que nos fichiers de tests soient à coté du fichier source correspondant
   - to run tests with an `npm` command
+  - à exécuter les tests avec la commende `npm` 
   - load the test file with SystemJS
+  - à charger les fichiers de tests avec SystemJS
 
 .callout.is-helpful
   header Prior Knowledge
+  header Connaissance prérequises
   :marked
     The Unit Testing chapters build upon each other. We recommend reading them in order.
+
+    Chaque châpitre sur les tests unitaires se base sur le précédent. Nous recommendons de les lires dans l'ordre.
+
     We're also assuming that you're already comfortable with basic Angular 2 concepts and the tools
     we introduced in the [QuickStart](../quickstart.html) and
     the [Tour of Heroes](../tutorial/) tutorial
     such as <code>npm</code>, <code>gulp</code>, and <code>lite-server</code>.
 
+    Nous nous attendons à ce que vous soyez déja habitué aux concepts basiques d'Angular 2 et aux outils 
+    que nous avons présentés dans le [Démarrage rapide]](../quickstart.html) et le
+    tutoriel [Tour des héros](../tutorial/) comme <code>npm</code>, <code>gulp</code>, and <code>lite-server</code>.
+
 .l-main-section
 :marked
   ## Create the test-runner HTML
 
+  ## Créer le code HTML pour l'éxécuteur de tests
+
   Locate the folder that contains the application `index.html` for your testing copy of Tour of Heroes.
 
+  Cherchez le répertoire contant le fichier `index.html` de l'application dans votre copie de test du Tour des héros.
+
   Create a new, sibling HTML file, ** `unit-tests.html` ** and copy over the same basic material from the  `unit-tests.html` in the [Jasmine 101](./jasmine-testing-101.html) chapter.
+
+  Créez un nouveau fichier HTML à coté de celui-ci, ** `tests-unitaires.html` ** et copiez encore le même code de base depuis le fichier `tests-unitaires.html` écrit dans le chapitre [Débuter avec les tests Jasmine](./jasmine-testing-101.html).
   
 +makeExample('testing/ts/unit-tests-2.html', 'test-runner-base', 'unit-tests.html')
 
++makeExample('testing/ts/unit-tests-2.html', 'test-runner-base', 'tests-unitaires.html')
+
 :marked
   We're picking up right where we left off. All we've done is change the title.
 
+  Nous reprennons pile là où nous nous étions arrété. Tout ce que nous avons fait, c'est changer le titre.
+
 .l-main-section
 :marked
   ## Update `package.json` for testing
 
+  ## Mise à jour de `package.json` pour les tests
+
   We must install the Jasmine package as well:
 
+  Nous devons également installer le package Jasmine:
+
 pre.prettyprint.lang-bash
   code npm install jasmine-core --save-dev --save-exact
 
 .alert.is-important Be sure to install <code>jasmine-core</code> , not <code>jasmine</code>!
+.alert.is-important Vérifiez à bien installer <code>jasmine-core</code> , pas <code>jasmine</code>!
 
 .l-main-section
 :marked
   ## Configure `lite-server` for serving our test harness
 
+  ## Configurer `lite-server` pour servir notre harnais de tests
+
 :marked
   First create a configuration file for serving up our test harness through `lite-server`.
 
+  Commençons par créer un fichier de configuration pour servir le harnais de test avec `lite-server`.
+
 +makeExample('testing/ts/liteserver-test-config.json', '', 'liteserver-test-config.json')
 
 :marked
   Let's make one more change to the `package.json` script commands.
 
+  Allons faire une autre modification dans les commandes de scripts de `package.json`.
+
   **Open the `package.json` ** and scroll to the `scripts` node and add the following two entries:
 
+  **Ouvrez `package.json` ** et allez au noeud `scripts` pour y ajouter les deux entrés suivantes:
+
 code-example(format="").
   "lite-server-test": "lite-server --config=liteserver-test-config.json",
   "test": "tsc && concurrently \"npm run tsc:w\" \"npm run lite-server-test\" "
@@ -62,91 +103,156 @@ code-example(format="").
 :marked
   The `npm test` command will launch `lite-server` and open a browser to the `unit-tests.html` page we just wrote. It will also take care of recompiling your source code and reloading your browser after any change.
 
+  La commande `npm test` va lancer `lite-server` et ouvrir un navigateur sur la page  `tests-unitaires.html` que nous venons d'écrire. Il va aussi s'occuper de recompiler votre code source et va re-actualiser le navigateur aprés chaques changements.
+
 .l-main-section
 :marked
   ## First app tests
 
+  ## Premier tests de l'app
+
   We can start testing *some* of our app right away. For example, we can test the `Hero` interface:
+
+  Nous pouvons directement commencer par tester *quelques* parties de notre application:
   
 +makeExample('testing/ts/app/hero.ts')  
 
 :marked
   Let's add a couple of simple tests in a new file.
 
+  Ajoutons quelques tests dans un nouveau fichier.
+
 +makeExample('testing/ts/app/hero.spec.ts', 'base-hero-spec')  
 
 :marked
   That's the basic Jasmine we learned back in "Jasmine 101".
 
+  Ce sont les bases que nous avons apprises dans "Débuter avec les tests Jasmine".
+
   Notice that we surrounded our tests with ** `describe('Hero')` **.
 
+  Notez que nous avons entouré nos tests avec ** `describe('Hero')` **.
+
   **By convention, our test always begin with a `describe` that identifies the application part under test.**
 
+  **Par convention, nos tests commencent toujours avec un `describe` qui identifie la partie de l'application que nous testons.**
+
   The description should be sufficient to identify the tested application part and its source file. Almost any convention will do as long as you and your team follow it consistently and are never confused.
+
+  La description doit être suffisante pour identifier la partie testée et son fichier source. Presque toutes les conventions feront l'affaire, temps que vous et votre équipe les suivez correctements et que vous n' êtes jamais perdus.
   
   But we haven't saved this test yet.
 
+  Mais nous n' avons pas encore sauvegardé ce test.
+
 .l-main-section
 :marked
   ## Where do tests go?
 
+  ## Où vont les tests?
+
   Some people like to keep their tests in a `tests` folder parallel to the application source folder.
 
+  Certaines personnes aiment garder leurs tests dans un répertoire `tests` parallèle au répertoire des sources de l'application. 
+
   We are not those people. We like our unit tests to be close to the source code that they test. We prefer this approach because
+
+  Nous ne sommes pas ces personnes. Nous voulons que nos tests soient à coté du code source testé. Nous préférons cette approche car
+
   - The tests are easy to find
-  - We see at a glance if an application part lacks tests.
+  - Les tests sont plus facile à trouver
+  - We see at a glance if an application part lacks tests
+  - Nous voyons d'un coup d'oeil quelles parties de l'application ne sont pas testées
   - Nearby tests can teach us about how the part works; they express the developers intention and reveal how the developer thinks the part should behave under a variety of circumstances.
+  - Les tests proches nous apprennent comment fonctionne le code; ils expriment les intentions du développeur et comment le développeur à pensé au comportement de ce code dans une variété de circonstances.
   - When we move the source (inevitable), we remember to move the test.
+  - Quand nous déplaçons les sources (inévitable), nous pensons à déplacer les tests.
   - When we rename the source file (inevitable), we remember to rename the test file.
+  - Quand nous renommons les sources (inévitable), nous pensons à renommer les fichiers tests. 
 
   We can't think of a downside. The server doesn't care where they are.  They are easy to find and distinguish from application files when named conventionally.
 
+  Nous ne pouvons pas y trouver de mauvais cotés. Le serveur ne se préocupe pas d'où ils se trouvent. Ils sont faciles à trouver et se distinguent des fichiers de l'application quand ils sont nommés en suivant les conventions.
+
 .l-sub-section
   :marked
     You may put your tests elsewhere if you wish. 
+
+    Vous pouvez mettres vos tests ailleur si vous le voulez.
+
     We're putting ours inside the app, next to the source files that they test.
 
+    Nous mettons les notres dans l'application, à coté des fichiers sources qu'ils testent.
+
 .l-main-section
 :marked
   ## First spec file
 
+  ## Premier fichier spec
+
   **Create** a new file, ** `hero.spec.ts` ** in `app` next to `hero.ts`.
 
+  **Créez** un nouveau fichié, ** `hero.spec.ts` ** dans `app` à coté de `hero.ts`.
+
   Notice the ".spec" suffix in the test file's filename, appended to the name of the file holding the application part we're testing.
 
+  Notez le ".spec" suffixe dans le nom du fichier de test, ajouté au nom du fichier contenant la partie de l'application que nous testons.
+
 .alert.is-important  All of our unit test files follow this .spec naming pattern.
 
+.alert.is-important  Tout nos fichiers de tests unitaires suivent ce format .spec.
+
 :marked
   Save the tests we just made in `hero.spec.ts`:
 
+  Sauvegardez les tests que nous venons de faire dans `hero.spec.ts`: 
+
 +makeExample('testing/ts/app/hero.spec.ts', 'base-hero-spec')  
 
 :marked
   ### Import the part we're testing
 
+  ### Importez la partie que nous testons
+
   We have an `import {Hero} from './hero' ` statement.
 
+  Nous avons la déclaration `import {Hero} from './hero'.
+
   If we forgot this import, a TypeScript-aware editor would warn us, with a squiggly red underline, that it can't find the definition of the `Hero` interface.
 
+  Si nous oublions cet import, un éditeur supportant TypeScript devrait nous avertir, avec une soulignage rouge ondulé, qu'il ne trouve pas la définition de l'interface `Hero`.
+
   ### Update unit-tests.html
 
+  ### Mise à jour de tests-unitaires.html
+
   Next we update the `unit-tests.html` with a reference to our new `hero.spec.ts` file. Delete the inline test code.  The revised pertinent HTML looks like this:
+
+  Par la suite, nous mettons à jour `tests-unitaires.html` avec une référence vers notre nouveau fichier `hero.spec.ts`. Supprimez le code de testé en ligne. Le code HTML modifié ressemble à ca 
   
 +makeExample('testing/ts/unit-tests-2.html', 'load-hero-and-spec')(format=".")
 
 :marked
   ### Run and Fail
 
+  ## Exécution et echec
+
   Look over at the browser (lite-server will have reloaded it).  The browser displays
 
+  Regardez le navigateur (lite-server l'aura re-actualisé). Le navigateur affiche
+
 figure.image-display
   img(src='/resources/images/devguide/first-app-tests/Jasmine-not-running-tests.png' style="width:400px;" alt="Jasmine not running any tests")
 
 :marked
   That's Jasmine saying "**things are _so_ bad that _I'm not running any tests_.**"
 
+  Il s'agit de Jasmine qui dit "**les choses vont _si_ mal que _je ne vais éxécuter aucun test_.**"
+
   Open the browser's Developer Tools (F12, Ctrl-Shift-i). There's an error:
 
+  Ouvrez les Outils développeur du navigateur (F12, Ctrl-Shift-i). Il y a une erreur:
+
 code-example(format="" language="html").
   Uncaught ReferenceError: System is not defined
 
@@ -154,31 +260,54 @@ code-example(format="" language="html").
 :marked
   ## Load tests with SystemJS
 
+  ## Chargez les tests avec SystemJS
+
   The immediate cause of the error is the `export` statement in `hero.ts`.
   That error was there all along.
   It wasn't a problem until we tried to `import` the `Hero` interface in our tests.
 
+  La cause directe de cette erreur est la déclaration `export` dans `hero.ts`. 
+  Cette erreur était là depuis le début.
+  Ce n'était pas un problème jusqu'a ce que nous essayons d' `import` l'interface `Hero` dans nos tests.
+
   Our test environment lacks support for module loading.
   Apparently we can't simply load our application and test scripts like we do with 3rd party JavaScript libraries.
 
+  Il manque à notre environement de test le support pour le chargement de modules.
+  Apparemment nous ne pouvons pas simplement charger notre application et les scripts de tests comme nous le ferions pour une librairies JavaScript tierce.
+
   We are committed to module loading in our application.
   Our app will call `import`.  Our tests must do so too.
 
+  Nous nous sommes engagés à utiliser le chargement des modules dans notre application. 
+  Notre application appelle `import`. Nos tests doivent en faire autant. 
+
   We add module loading support in four steps:
 
+  Nous ajoutons le support du chargement des modules en quatres étapes:
+
   1. add the *SystemJS* module management library
+  1. ajouter la librairie de gestion de modules *SystemJS*
   1. configure *SystemJS* to look for JavaScript files by default
+  1. configurer *SystemJS* pour chercher des fichiers JavaScript par défaut
   1. import our test files
+  1. importer nos fichiers de tests
   1. tell Jasmine to run the imported tests
+  1. informer Jasmine d'éxécuter les tests importés
 
   These steps are all clearly visible, in exactly that order, in the following lines that
   replace the `<body>` contents in `unit-tests.html`:
 
+  Ces étapes sont clairements visibles, éxactement dans le même ordre, 
+  dans les lignes suivantes qui remplacent la section `<body>` dans `tests-unitaires.html`:
+
 +makeExample('testing/ts/unit-tests-3.html', 'systemjs')(format=".")
 
 :marked
   Look in the browser window. Our tests pass once again.
 
+  Regardons dans la fenêtre du navigateur. Nos tests passent à nouveau.
+
 figure.image-display
   img(src='/resources/images/devguide/first-app-tests/test-passed-once-again.png' style="width:400px;" alt="Tests passed once again")
 
@@ -188,37 +317,70 @@ figure.image-display
   ## Observations
 
   ### System.config
+
   System.js demands that we specify a default extension for the filenames that correspond to whatever it is asked to import.
   Without that default, it would translate an import statement such as `import {Hero} from './hero'` to a request for the file named `hero`.
   Not `hero.js`. Just plain `hero`.  Our server error with "404 - not found" because it doesn't have a file of that name.
 
+  System.js demande à ce que nous spécifions une extension par défaut pour les noms de fichiers correspondant à ce qui va être demandé à importer.
+  Sans ce défaut, om traduit une déclration d'importation comme `import {Hero} from './hero'` en une requête vers un fichier nommé `hero`.
+  Pas `hero.js`. Juste `hero`. Notre serveur retourne alors une erreur "404 - not found" car il ne trouve de fichier avec ce nom. 
+
   Once configured with a default extension of 'js',&nbsp;  SystemJS requests `hero.js` which *does* exist and is promptly returned by our server.
 
+  Une fois configuré avec une l' extension par défaut 'js',&nbsp; SystemJs effectue la requête récupérer le fichier `hero.js` qui lui existe et le retourne directement.  
+
   ### Asynchronous System.import
+  ### System.import asynchrone
+
   The call to `System.import` shouldn't surprise us but its asynchronous nature might.
   If we ponder this for a moment, we realize that it must be asynchronous because
   System.js may have to fetch the corresponding JavaScript file from the server.
   Accordingly, `System.import` returns a promise and we must wait for that promise to resolve.
   Only then can Jasmine start evaluating the imported tests.
 
+  L'appel à `System.import` ne devrait pas nous surprendre, mais ca nature asynchrone elle le pourrait.
+  Si nous réfléchissons à cela un instant, nous réalisons qu'elle doit être asynchrone car System.js doit récupérer le fichier JavaScript correspondant depuis le serveur.
+  En conséquence, `System.import` retourne une promesse et nous devons attendre que cette promesse soit résolue.
+  Alors seulement, Jasmine pourra évaluer le test importé.
+
   ### window.onload
+
   Jasmine doesn't have a `start` method.  It wires its own start to the browser window's `load` event.
   That makes sense if we're loading our tests with script tags.
   The browser raises the `load` event when it finishes loading all scripts.
 
+  Jasmine n'a pas de méthode `start`. La librairie cable son propre démarage sur l'évènement navigateur `load`.
+  Cela semble logique si  nous chargeons nos tests avec des balises scripts.
+
   But we're not loading test scripts inline anymore.
   We're using the SystemJS module loader and it won't be done until long after the browser raised the `load` event.
   Meanwhile, Jasmine started and ran to completion … with no tests to evaluate … before the import completed.
 
+  Mais nous ne chargeons plus nos scripts de cette manière.
+  Nous utilisons le chargeur de module SystemJS et ce ne sera fait seulement longtemp aprés que l'évènement `load` est était émis. 
+
   So we must wait until the import completes and only then call the window `onLoad` handler.
   Jasmine re-starts, this time with our imported test queued up.
 
+  Nous devons donc attendre jusqu'a ce que l'importation soit terminée, alors seulement nous pourrons appeller la fonction `onLoad`.
+  Jasmine re démarera, cette fois avec nos test prêt à être exécutés. 
+
 .l-main-section
 :marked
   ## What's Next?
+  ## Quoi de neuf pour la suite ?
+
   We are able to test a part of our application with simple Jasmine tests.
   The part was a stand-alone interface that made no mention or use of Angular.
 
+  Nous sommes capable de tester une partie de notre application avec des tests Jasmine simples.
+  Cette partie était une interface isolée qui ne mentionnée pas et n'utilisée pas Angular.
+
   That's not rare but it's not typical either. 
   Most of our application parts make some use of the Angular framework.
   Let's test a *pipe* class that does rely on Angular.
+
+  Ce n'est pas rare, mais ce n'est pas non plus un cas typique.
+  La pluparts des parties de notre application utilise d'une manière ou d'une autre le framework Angular.
+  Essayons de tester une classe qui utilise Angular pour implementer un *tuyaux*. 
diff --git a/public/docs/ts/latest/testing/jasmine-testing-101.jade b/public/docs/ts/latest/testing/jasmine-testing-101.jade
index 082d2d08..2086dca4 100644
--- a/public/docs/ts/latest/testing/jasmine-testing-101.jade
+++ b/public/docs/ts/latest/testing/jasmine-testing-101.jade
@@ -2,24 +2,45 @@ include ../_util-fns
 
 :marked
   We’ll write our tests with the [Jasmine test framework](http://jasmine.github.io/2.3/introduction.html).
+
+  Nous allons écrire nos tests avec le [framework de test Jasmine](http://jasmine.github.io/2.3/introduction.html).
+  
   We’ll start by getting *some* tests to work - *any* tests at all.
 
+  Nous allons commencer par faire fonctionner **quelques** tests.
+
   We will learn
+
+  Nous allons apprendre
+
     - basic Jasmine testing skills
+    - les compétences de base pour tester avec Jasmine
     - to run our tests in the browser
+    - à exécuter nos tests dans le navigateur
     - to write simple Jasmine tests in TypeScript
+    - à écrire des tests simple avec Jasmine en TypeScript
     - to debug a test in the browser
+    - à débuffer un test dans le navigateur
 
   **Create a new project folder** perhaps called `angular2-unit-testing`.
+
+  **Créez un nouveau dossier** appellé, par exemple, `angular2-test-unitaire`.
+
 .l-main-section
 :marked
   ## Install npm packages locally
+  ## Installer les paquets npm localement
 
   Next follow all of  the steps prescribed in  “Install npm packages locally” of the
   [QuickStart](../quickstart.html).
 
+  Suivez toutes les étapes décrites dans la section “Installer un paquet npm locallement” du
+  [démarrage rapide](../quickstart.html).
+
   We’ll also add the Jasmine package via `npm`:
 
+  Nous avons également ajouté le paquet Jasmine via `npm`: 
+
 pre.prettyprint.lang-bash
    code npm install jasmine-core --save-dev --save-exact
 
@@ -27,78 +48,123 @@ pre.prettyprint.lang-bash
   :marked
     Be sure to install `jasmine-core` , not `jasmine`!
 
+    Soyez sur de bien installer `jasmine-core` , pas `jasmine`!
+
 :marked
   **Create a sub-folder `src` ** for our tests and then **cd into it**.
 
+  **Créez un sous répertoire `src` ** pour nos tests et aprés **cd dedant**.
+
   We are going to **display and control our tests in the browser**.
 
+  Nous allons **afficher et controller nos test dans le navigateur**.
+
 .l-sub-section
   :marked
     The browser is nice during development of a few tests. It’s not the best venue for working with a lot of tests and it won’t do at all for build automation. We’ll switch to the karma test-runner when the time comes. But the browser will do for now.
 
+    Le navigateur est intéressant durant le développement de quelques test. Ce n'est pas le meilleur outil pour travailler avec de nombreux tests et il ne conviendra pas du tout lors de l'automatisation des constructions. Mais pour le moment, le navigateur suffira.
+
 :marked
   Create a new file called`unit-tests.html` and enter the following:
-+makeExample('testing/ts/unit-tests-0.html', 'no-script', 'unit-tests.html')
+
+  Créez un nouveau fichié appelé `tests-unitaires.html` et tappez ce qui suit:
++makeExample('testing/ts/unit-tests-0.html', 'no-script', 'tests-unitaires.html')
 
 :marked
   In the head we have three Jasmine scripts and one Jasmine css file. That’s the foundation for running any tests.
 
+  Dans la balise head nous avons trois scripts Jasmine et un fichier css Jasmine. Ce sont les fondations pour exéctuer n'importe quel test.
+
   We’ll write our first test with inline JavaScript inside the body tag:
 
+  Nous allons écrire notre premier test avec du code Javascript en ligne dans la balise body:
 
 +makeExample('testing/ts/unit-tests-0.html', 'body')(format='.')
 
 :marked
   Now open `unit-tests.html` in a browser and see the Jasmine HTML test output:
 
+  Maintenant ouvrez `tests-unitaires.html` dans un navigateur et regardez la sortie HTML du test Jasmine:
+
 figure.image-display
     img(src='/resources/images/devguide/jasmine-testing-101/jasmine-1-spec-0-failures.png' style="height:170px;" alt="Jasmine HTML test output")
 
 :marked
   It doesn’t get much simpler than that!
 
+  Ca ne peut pas être plus simple que ça.
+
 .l-main-section
 :marked
   ## First TypeScript Test
+  ## Premier test TypeScript
+
   Perhaps too simple. We won’t write our entire test suite inside one HTML file.
+  
+  Peut-être trop simple. Nous n'alllons pas écrire entierement notre suite de tests dans un fichier HTML.
+
   Let’s **extract** that line of test code to a **new file in `src` called `1st.spec.ts` ** .
 
+  Nous allons **extraire** ces lignes de code de test vers un **nouveau fichier dans `src`appellé `1st.spec.ts` ** .
+
 .l-sub-section
   :marked
     Among Jasmine developers, a test is known as a “spec” and test filenames include the word “spec”.  We’ll stick with that convention.
 
+    Parmis les développeurs Jasmine, un test est connue sous l'appellation de “spec” et les noms des fichiers tests incluent le mot “spec”. Nous allons suivre cette convention. 
+
 :marked
   The test we wrote is valid TypeScript because any JavaScript is valid TypeScript. But let’s make it more modern with an arrow function:
+
+  Le test que nous écrivons est du TypeScript valide, car tout JavaScript est du TypeScript valide. Mais rendons cela plus moderne en utilisant les fonctions flèches:
   
 +makeExample('testing/ts/1st.spec.ts', 'it', '1st.spec.ts')
 
 :marked
   Now modify `unit-tests.html` to load the script:
   
+  Maintenant modifions `tests-unitaires.html`pour charger le script:
+
 +makeExample('testing/ts/unit-tests-1.html', 'script')
 
 :marked
   Hold on! We wrote a TypeScript file but we’re loading a JavaScript file?
 
+  Attendez! Nous écrivons un fichier TypeScript mais nous chargeons un fichier JavaScript? 
+
   That’s a reminder that we need to compile our TypeScript test files as we do our TypeScript application files.  Do that next.
 
+  C'est un rappel sur le fait que nous devons compiler nos fichiers de test TypeScript pendant que nous écrivons les fichiers de notre application. C'est ce que nous allons faire. 
+
 .l-main-section
 :marked
   ## Prepare for TypeScript
 
+  ## Préparons nous pour TypeScript
+
   As we’ve seen before, we first have to tell the compiler how to compile our TypeScript files with
   a ** `tsconfig.json` **.
 
+  Comme nous l'avons vu avant, nous devons en premier dire au compilateur comment compiler nos fichiers TypeScript avec un ** `tsconfig.json` **. 
+
   We can copy one from the quickstart we wrote previously and paste it into our src sub-folder.
   It should look something like this:
 
+  Nous pouvons copier celui que nous avons écrit pour le démarrage rapide et le copier dans le sous répertoire src.
+  Cela devrait ressembler à quelque chose comme: 
+
 +makeExample('testing/ts/tsconfig.1.json', null, 'tsconfig.json')
 
 :marked
   ## Compile and Run
 
+  ## Compilation et exécution
+
   Compile in the terminal window using the npm script command
 
+  Compiler dans une fenètre de terminal en utilisant la commande npm script
+
 pre.prettyprint.lang-bash
   code npm run tsc
 
@@ -108,94 +174,152 @@ pre.prettyprint.lang-bash
     what `it` and `expect` are because they lack the typing files that describe Jasmine.
     We can ignore those annoying complaints for now as they are harmless.
 
+    Notre éditeur et le compilateur risque de se plaindrent car ils ne savent pas ce que sont `it` et `expect` car il nous manque les fichiers de définition de types de Jasmine.
+    Nous pouvons ignorer ces alertes pour le moment, car elles ne sont pas dangereuses.
+
 :marked
   If we reload the browser, we should see the same Jasmine test-runner output as before.
 
+  Si nous re-actualisons le navigateur, nous devrions voir le même résultat de sortie de Jasmine que précédemment.
+
   We’ll be evolving these tests rapidly and it would be nice to have the browser refresh automatically as we make changes and recompile.
 
+  Nous allons faire évoluer ces tests rapidement et il serrait bien que le navigateur s'actualise automatiquement lors de nos modifications et recompilations.
+
   Let’s launch with **lite-server** in a second terminal window:
 
+  Lançons **lite-server** dans un second terminal:
+
 pre.prettyprint.lang-bash
   code npm start
 
 :marked
   Now reload `unit-tests.html` in the browser
 
+  Maintenant re-actualisez `tests-unitaires.html` dans le navigateur 
+
   We should get the same Jasmine test-runner output as before.
 
+  Nous devrions voir le même résultat de sortie de Jasmine que précédemment.
+
 .l-main-section
 :marked
   ## Add a describe and another test
 
+  ## Ajouter une description et un autre test
+
   We can’t tell what file produced these test results. We only have one file at the moment but soon we’ll write more.
 
+  Nous ne pouvons pas dire quel fichier à produit ces résultats de test. Nous n'avons qu'un fichier pour le moment, mais nous allons bientôt en avoir plus.
+
   We should wrap this test into something that identifies the file. In Jasmine that “something” is a `describe` function.  Every test file should have at least one `describe` that identifies the file holding the test(s).
 
+  Nous devrions envelopper ces tests dans quelque chose qui identifie le fichier. Avec Jasmine, ce “quelque chose” est une fonction `describe`. Chaque fichier test doit avoir au moins un `describe` qui identifie le fichier contenant le(s) test(s).  
+
   Here’s what our revised `1st.spec.ts` looks like when wrapped in a `describe`:
 
+  Voilà ce à quoi ressemble notre `1st.spec.ts` modifié pour utiliser `describe`:
+
 +makeExample('testing/ts/1st.spec.ts', 'describe')
 
 :marked
   And here’s how the test report displays it.
 
+  Et voila comment notre rapport de test affiche cela.
+
 figure.image-display
     img(src='/resources/images/devguide/jasmine-testing-101/test-report-1-spec-0-failures.png' style="height:100px;" alt="1 spec, 0 failures")
 
 :marked
   Let’s add another Jasmine test to `1st.spec.ts`
+
+  Ajoutons un autre test Jasmine à `1st.spec.ts`
   
 +makeExample('testing/ts/1st.spec.ts', 'another-test')(format=".")
 
 :marked
   You knew that right?  Let’s prove it with this test. The browser should refresh after you paste that test, and show:
 
+  Vous le saviez ça? Exact? Prouvons le avec un test. Le navigateur devrait se re-actualiser aprés que vous ayez copié le test, et afficher:
+
 figure.image-display
     img(src='/resources/images/devguide/jasmine-testing-101/test-report-2-specs-0-failures.png' style="height:100px;" alt="refreshed 2 specs, 0 failures")
 
 :marked
   What does a failing test look like? Remove the `.not`. The browser refreshes and shows:
 
+  A quoi ressemble un test qui échoue? Enlevez le `.not`.Le navigateur se re-actualise et affiche:
+
 figure.image-display
     img(src='/resources/images/devguide/jasmine-testing-101/test-report-2-specs-1-failure.png' style="height:190px;" alt="failing test 2 specs, 1 failure")
 
 :marked
   Click the `Spec List` link just below “2 specs, 1 failure” to see the summary again:
 
+  Cliquez sur le liens `Spec List` juste sous “2 specs, 1 failure” pour voir une nouvelle fois le résumé:
+
 figure.image-display
     img(src='/resources/images/devguide/jasmine-testing-101/spec-list-2-specs-1-failure.png' style="height:140px;" alt="2 specs, 1 failure")
 
 :marked
   We can re-run just the failing test by double-clicking it.  Try it!
 
+  Nous pouvons re-exécuter le test qui échoue en double cliquant dessus. Essayez!
+
 .l-main-section
 :marked
   ## Debug the test
+
+  ## Débugger le test 
+
   Suppose we didn’t know what was going on.  We can debug it in the browser.
 
+  Supposons que nous ne sachions pas ce qu'il se passe. Nous pouvons débugger le test dans le navigateur.
+
     - Open the browser’s “Developer Tools” (F12 or Ctrl-Shift-I).
+    - Ouvrez la fenêtre “Outils développeurs” (F12 or Ctrl-Shift-I).
     - Pick the “sources” section
+    - Selectionnez la section “sources” 
     - Open the `1st.spec.ts` test file (Ctrl-P, then start typing the name of the file).
+    - Ouvrez le fichier de test `1st.spec.ts` (Ctrl-P, puis commencez à tapper le nom du fichier). 
     - Set a breakpoint on the second line of the failing test
+    - Placez un point d'arret sur la seconde ligne du test qui échoue
     - Refresh the browser … and it stops at our breakpoint.
+    - Re-actualisez le navigateur ... et il s'arrète sur notre point d'arret.
     - Open the console window at the bottom  (press Esc)
+    - Ouvrez le fenètre de la console en bas (appuyez sur Esc)
     - Type `null === undefined` … … and we should see this:
+    - Tappez `null === undefined` ... ... et nous devrions voir ça:
 
 figure.image-display
     img(src='/resources/images/devguide/jasmine-testing-101/null-to-equal-undefined.png' style="height:500px;" alt="null === undefined")
 
 :marked
   How about that!  They really aren’t equal.
+
+  Comment ça! Ils ne sont vraiment pas égaux.
+
     - remove the breakpoint (right-click in the “Breakpoints” section and chose “Remove breakpoint”)
+    - supprimez le point d'arret (clic droit dans la section “point d'arrets” et selectionnez “Supprimer un point d'arret”)
     - Click the “play” icon to resume the test  (or F8)
+    - Cliquez sur l'icone “play” pour reprendre le test (ou F8) 
 
   And the test finishes.  Close the browser tools (click the close box or press F12 or Ctrl-Shift-I)
 
+  Et le test se termine. Fermez les outils du navigateur (cliquez sur le bouton de fermeture ou appuyez sur F12 ou Ctrl-Shift-I)
+
   Fix the test (restore the `.not`);  the browser should refresh automatically and all tests pass.
 
+  Réparez le test (remettez le `.not`); le navigateur devrait se re-actualiser automatiquement et tout les tests devraient passer.
+
   Congratulations … you’ve completed Jasmine testing 101.
+
+  Félicitation ... vous venez de terminer votre initiation à Jasmine.
   
   Now that we’re familiar with Jasmine on its own, we’re ready to test an application.
 
+  Maintenant que vous êtes familié avec Jasmine, nous sommes prêts pour tester une application.
+
   <!-- TODO
   .l-main-section
   :marked
diff --git a/public/docs/ts/latest/testing/testing-an-angular-pipe.jade b/public/docs/ts/latest/testing/testing-an-angular-pipe.jade
index dcd68a54..a1320543 100644
--- a/public/docs/ts/latest/testing/testing-an-angular-pipe.jade
+++ b/public/docs/ts/latest/testing/testing-an-angular-pipe.jade
@@ -3,61 +3,116 @@ include ../_util-fns
 :marked
   We’ll test an Angular pipe in this chapter.
 
+  Nous allons tester un tuyau Angular dans ce chapitre.
+
   An Angular pipe is a declarative way in HTML to transform some input into some displayable output.
+
+  Un tuyau Angular est un moyen déclaratif en HTML de transformer une entre en une sortie affichable.
   
   We don't have a pipe though, since in Tour of Heroes we didn't create any pipes. It uses a pipe though, the `uppercase` pipe that comes with Angular 2.
+
+  Nous n'avons cependant pas de tuyaux, car nous n'en avons pas créé. Il utilise cepandant un tuyau, le tuyau `uppercase` fournit par Angular 2.
   
   We can make our own `my-uppercase` pipe that does exactly the same as the `uppercase` pipe and test that.
+
+  Nous allons faire notre propre tuyau `my-uppercase` qui fait éxactement la même chose que le tuyau `uppercase` et le tester.
   
   Since we're getting ready to write some code we want to test, let's take this opportunity to talk just a little bit about [Test Driven Development](https://en.wikipedia.org/wiki/Test-driven_development). There's a lot written about this topic so we don't want to have an exhaustive description here, but rather a practical application.
+
+  Vue que nous sommes prêt à écrire le code que nous voulons tester, nous allons saisir cette opportunité pour parler un petit peut de [Développement piloté pas les tests](https://fr.wikipedia.org/wiki/Test_driven_development). Il y a beaucoup de resources écrites sur ce sujet, alors nous n'allons 
+  pas en faire une description exhaustive ici, nous allons plutôt parler de ces applications pratiques. 
   
   We already know *exactly* what we want the `uppercase` pipe to do. We could say our ...expectations... of it are very well defined.
+
+  Nous savons déja *exactement* ce que doit faire le tuyau `uppercase`. Nous pourrions dire que nos ...attentes... concernant celui-ci sont trés bien définies.
   
   We always use our expectations to guide development, but sometimes it's hard to see the forest for the trees when we're right in the middle of coding. This is especially evident in larger tasks.
+
+  Nous utilisons toujours nos attentes pour guider le développement, mais certaines fois quand nous sommes en plein milieu d'un développement, les arbres peuvent cacher une forêt. Cela est particulièrement vrais pour de grandes tâches.
   
   So one thing we can do is put those expectations down as cold hard test code. We were going to test things manually anyway, so doing it *before* we have even one line of code isn't going to hurt. 
   
+  Alors une chose que nous pouvons faire, c'est de spécifier ces attentes froidement, en dur, dans du code de test. Nous allions dans tout les cas tester les choses manuellement, alors le faire *avant* même d'avoir une seule ligne de code ne va pas nous déranger.
+
   Worst thing that can happen is have that test fail, but on the way to fixing it we'll end up creating our pipe. So in a sense, the failing test will *tell you what it wants* to pass.
+
+  La pire chose qui puisse arriver est que nos tests échouent, mais au fur et à mesure que nous les réparerons, nous finirons par créer le tuyau. Donc d'une manière, le test qui échoue *vous dira ce qu'il veut* pour fonctionner. 
   
   We're just putting down expectations, nothing more. If we were to put them down on paper, they would look like this:
 
+  Nous allons juste poser nos attentes, rien de plus. Si nous devions les écrires sur papier, elles ressembleraient à cela:
+
   ```  
     MyUppercasePipe
       transforms "abc" to "ABC"
       transforms "abc def" to "ABC DEF"
       leaves "ABC DEF" unchanged
   ```  
+
+  ```  
+    MyUppercasePipe
+      transforme "abc" en "ABC"
+      transforme "abc def" en "ABC DEF"
+      ne modifie pas "ABC DEF" 
+  ```  
    
-  All we need to know to put down our expectations as code is how a pipe class looks like from the outside. From the [pipe developer guide](pipes#custom-pipes) we know that a pipe implements a `transform` method. 
+  All we need to know to put down our expectations as code is how a pipe class looks like from the outside. From the [pipe developer guide](pipes#custom-pipes) we know that a pipe implements a `transform` method.
+
+  Tout ce que nous devons savoir pour écrire nos attentes sous forme de code est à quoi la classe tuyau ressemble depuis l'extérieur. Grâce au [guide de développement de tuyaux](pipes#custom-pipes) nous savons qu'un tuyau implémente une méthode `transform`.   
   
   Putting it down as Jasmine expectations, they would look something like this:
+
+  Les écrire sous la forme d'attente avec Jasmine, elles devraient ressembler à cela:
   
 +makeExample('testing/ts/app/my-uppercase.pipe.spec.ts', 'expectations')  
 
 :marked
   In this chapter we will:
+
+  Dans ce chapitre nous allons:
+  
   - create a test before creating a class
+  - créer un test avant d'écrire une classe
   - load multiple test files in our test harness, using system.js
+  - charger plusieurs fichiers tests dans notre harnais, en utilisant system.js
   - add the Angular 2 library to our test harness
+  - ajouter la librairie Angular 2 à notre harnais de tests
   - watch the new test fail, and fix it
+  - regarder les nouveaux tests échouer, et les corriger
 
 .callout.is-helpful
   header Prior Knowledge
+  header Connaissances prérequises
   :marked
     The Unit Testing chapters build upon each other. We recommend reading them in order.
+
+    Chaque châpitre sur les tests unitaires se base sur le précédent. Nous recommendons de les lires dans l'ordre.
+    
     We're also assuming that you're already comfortable with basic Angular 2 concepts and the tools
     we introduced in the [QuickStart](../quickstart.html) and
     the [Tour of Heroes](../tutorial/) tutorial
     such as <code>npm</code>, <code>gulp</code>, and <code>lite-server</code>.
 
+    Nous nous attendons à ce que vous soyez déja habitué aux concepts basiques d'Angular 2 et aux outils 
+    que nous avons présentés dans le [Démarrage rapide]](../quickstart.html) et le
+    tutoriel [Tour des héros](../tutorial/) comme <code>npm</code>, <code>gulp</code>, and <code>lite-server</code>.    
+
 :marked
   ## Add another spec file
 
+  ## Ajoutez un autre fichier spec
+
   **Create** a `my-uppercase.pipe.spec.ts` in `app/`.
 
-  **Stop and restart the TypeScript compiler** to ensure we compile the new file.
+  **Créez** in fichier `my-uppercase.pipe.spec.ts` dans `app/`.
+
+  **Stop** and restart the TypeScript compiler** to ensure we compile the new file.
+
+  **Stoppez** et redémarrez le compilateur TypeScript** pour être sur qu'il compile bien le nouveau fichier.
 
   **Add** the following lines of rather obvious Jasmine test code.
+
+  **Ajoutez** les simples lignes de code Jasmine suivantes.
   
 +makeExample('testing/ts/app/my-uppercase.pipe.spec.ts', 'base-pipe-spec', 'app/my-uppercase.pipe.spec.ts')
   
@@ -65,117 +120,198 @@ include ../_util-fns
   Note that each test is short (one line in our case).
   It has a clear label that accurately describes the test. And it makes exactly one expectation.
 
+  Notez que chaque test est court (une ligne dans notre cas).
+  Il a un label clair qui décrit correctement le test. Et il décrit éxactement une seule attente.  
+
   Anyone can read these tests and understand quickly what the test does and what the pipe does.
   If one of the tests fails, we know which expected behavior is no longer true.
   We’ll have little trouble maintaining these tests and adding more like them as we encounter new conditions to explore.
 
+  N'importe qui peut lire ces tests et comprendre rapidement ce que fait le test et ce que fait le tuyau.
+  Si un test échoue, nous savons quel comportement attendu n'est plus vrai.
+  Nous allons avoir quelques petits problèmes pour maintenir ces tests et pour en ajouter d'autres au fur et  à mesure que nous rencontrerons de nouvelles conditions à explorer.
+
   That’s the way we like our tests!
 
+  C'est comme ca que nous aimons nos tests!
+
   ## Add this spec to `unit-tests.html`
 
+  ## Ajoutez cette spec à `tests-unitaires.html` 
+
   Now let’s wire our new spec file into the HTML test harness.
 
+  Maintenant allons cabler notre nouveau fichier de spec dans le harnais de tests HTML.
+
   Open `unit-tests.html`. Find `System.import('app/hero.spec')`.
 
+  Ouvrez `tests-unitaires.html`. Trouvez `System.import('app/hero.spec')`.
+
   Hmm. We can’t just add `System.import('app/my-uppercase.pipe.spec')`.
 
+  Hmm. Nous ne pouvons pas simplement ajouter `System.import('app/my-uppercase.pipe.spec')`.
+
   The first `System.import` returns a promise as does this second import.
   We can’t run any of the Jasmine tests until **both imports are finished**.
 
+  Le premier `System.import` retourne une promesse, tout comme le second import.
+  Nous ne pouvons pas éxécuter les tests Jasmines avant que **les deux imports soient finis**.
+
   Fortunately, we can create a new `Promise` that wraps both import promises and waits
   for both to finish loading.
     
+  Heureusement, nous pouvons créer une nouvelle `Promesse` qui englobe les deux promesses d'importation et attendre que les deux aient terminées de charger.
+
 +makeExample('testing/ts/unit-tests-4.html', 'promise-all')(format=".")
 
 :marked
   We have a pattern for adding new tests.
 
+  Nous avons maintenant un modèle pour ajouter de nouveaux tests.
+
   In future, when we add a new spec, we add another `System.import('app/some.spec')` to
   the array argument passed to `Promise.all`.
+
+  Dans le futur, quand nous ajouterons une nouvelle spécification, nous ajouterons un autre `System.import('app/some.spec')`  au tableau 
+  d'arguments passé à `Promise.all`.
   
   Try it. The browser should refresh and show the following in the console:
 
+  Essayez. Le navigateur devrait se rafraichir et afficher cela dans la console:
+
 code-example(format="" language="html" escape="html").
   GET http://localhost:8080/app/my-uppercase.pipe.js 404 (Not Found)
 
 :marked
   Our test failed, as expected. We're importing something that doesn't exist and our test fails saying that. All is going according to plan.
   
+  Notre test échoue, comme prévu. Nous importons quelque chose qui n'existe pas et nos tests échouent en nous le disant. Tout se déroule conformément au plan.
+
 :marked
   ## The pipe, if you please
   
+  ## Le tuyau, s'il vous plait.
+
   The test is asking for a pipe, and we shall deliver. 
+
+  Le test demande un tuyau, et nous devons le fournir.
   
   **Create** a `my-uppercase.pipe.ts` in `app/`.
+
+  **Créez** un fichier `my-uppercase.pipe.ts` dans `app/`.
   
   **Stop and restart the TypeScript compiler** to ensure we compile the new file.
   
+  **Stoppez et redémarrez le compilateur TypeScript** pour être sur qu'il compile bien le nouveau fichier.
+
   **Add** a basic pipe that doesn't do anything. We know how to make strings uppercase, but we since we're letting the test take the lead let's wait for it to tell us what's next. Maybe it'll surprise us.
-  
+
+  **Ajoutez** un tuyau basique qui ne fait rien. Nous savons comment capitaliser une chaine, mais comme nous laissons le test diriger, attendons le pour qu'il nous dise quoi faire. Cela pourrait peut-être nous surprendre.
+
 +makeExample('testing/ts/app/my-uppercase.pipe.1.ts', null, 'app/my-uppercase.pipe.ts')
 
 :marked
   Reload our test page and...
+
+  Re-actualisez la page de test et ...
   
 code-example(format="" language="html" escape="html").
   GET http://localhost:8080/angular2/core 404 (Not Found)
 
 :marked
   ## The Angular library, if you please
+
+  ## La librairie Angular s'il vous plait
+
   Looking back at `unit-tests.html` we realize that we have not loaded the Angular library.
   Yet we were able to load and test the application’s `Hero` interface.
 
+  En regardant `tests-unitaires.html` nous réalisons que nous n'avons pas chargé la librairie Angular.
+  Cepandant nous étions capable de charger et de tester l'interface `Hero` de l'application.
+
   **We were lucky!**  The `Hero` interface has no dependence on Angular.
   If it had depended on Angular, we’d still be staring at the Jasmine “big-time fail” screen:
 
+  **Nous étions chanceux!** L'interface `Hero` n'a pas de dépendances sur Angular.
+  Si elle avait dépendue d'Angular, nous serrions toujours en train de voir l'écran "sérieux problème":
+
 figure.image-display
   img(src='/resources/images/devguide/testing-an-angular-pipe/big-time-fail-screen.png' 
-      alt="Jasmine's' big time fail screen")
+      alt="Ecran sérieux problème de Jasmine")
 
 :marked
   We are writing an Angular application after all and
   we were going to need Angular sooner or later. That time has come.
 
+  Aprés tout nous sommes en train d'écrire une application Angular et nous allons avoir besoin d'Angular à un moment ou un autre. 
+  Ce moment est venu.
+
   `MyUppercasePipe` depends on Angular as is clear in the first few lines:
+
+  `MyUppercasePipe` dépend d'Angular, c'est clair dés les premières lignes:
   
 +makeExample('testing/ts/app/my-uppercase.pipe.ts', 'depends-on-angular')(format=".")
 
 :marked
   **Open** `unit-tests.html`
 
+  **Ouvrez** `tests-unitaires.html`
+
   **Find** the `<!-- #1. add the system.js library -->` comment.
 
+  **Trouvez** le commentaire `<!-- #1. add the system.js library -->`.
+
   **Replace** the scripts tags beneath it with the all the needed angular scripts:
 
+  **Remplacez** la balise de script qui se trouve dessous par tout les scripts Angular requis:
+
 +makeExample('testing/ts/unit-tests-5.html', 'import-angular')(format=".")
 
 :marked
   We should now be ready to see our 3 expectations fail when reloading our test page.
   
+  Vous devriez maintenant être prêt pour voir nos 3 attentes échouer quand la page de tests se ré-actualisera.
+
 figure.image-display
   img(src='/resources/images/devguide/testing-an-angular-pipe/two-failures.png' alt="2 failed tests")
     
 :marked
   ## Uppercase, if you please
   
+  ## Majuscule, s'il vous plait
+
   The first two tests that passed were our old `hero` interface tests, so it makes sense that those passed. Of our three new expectations, one still passed though.
+
+  Les deux premiers tests passés sont nos vieux tests de l'interface `hero`, c'est donc logique qu'il aient fonctionnées. Sur nos trois nouvelles attentes, une est quand même passée.
   
   ```  
     MyUppercasePipe
       transforms "abc" to "ABC"
       transforms "abc def" to "ABC DEF"
       leaves "ABC DEF" unchanged
+
   ```  
-  
+    MyUppercasePipe
+      transforme "abc" en "ABC"
+      transforme "abc def" en "ABC DEF"
+      ne modifie pas "ABC DEF" 
+  ```  
+
   Ah but of course! Our simple pipe doesn't transform the input at all, and the third test expected
   input to not be changed.
+
+  Mais bien sur! Notre pipe simpliste ne transforme pas son entré du tout, et le troisième test s'attend à ce que l'entré ne change pas. 
   
   All we have to do now is actually transform text to uppercase in our pipe.
   
+  Tout ce que nous avons à faire maintenant, c'est de transformer notre texte en majuscule dans le tuyau.
+
 +makeExample('testing/ts/app/my-uppercase.pipe.ts', 'uppercase')(format=".")
 
 :marked
   Are we done now?
+
+  Avons nous fini maintenant?
   
 figure.image-display
   img(src='/resources/images/devguide/testing-an-angular-pipe/zero-failures.png' alt="0 failed tests")
@@ -183,17 +319,32 @@ figure.image-display
 :marked
   The glorious green is back with us again!
   
+  Le glorieux vert est de nouveau de retour avec nous!
+
   We tried a bit of test driven development and it seems to have guided us to success.
+
+  Nous avons gouté au développement piloté par les tests et il semble que cela nous ai guidé vers le succés.
   
-  But it's not always feasible. For instance, sometimes we need to write tests for existing functionality, like what we're about to do with the rest of Tour of Heroes. 
+  But it's not always feasible. For instance, sometimes we need to write tests for existing functionality, like what we're about to do with the rest of Tour of Heroes.
+
+  Mais ce n'est pas toujours faisable. Par exemple, certaines fois nous devons écrire des tests pour des fonctionnalités existantes, comme nous allons le faire pour le reste du Tour des Héros. 
   
   If we are writing new code though, writing tests might just be what we need to help us track our progress and keep the end result in sight at all times.
 
+  Cepandant, si nous écrivons du nouveau code, écrire les tests pourrait être éxactement ce que nous avons besoin pour nous aider à suivre notre progression et garder en permanence le résultat final en vue.
+
 :marked
   ## What’s Next?
+  ## Quoi de neuf pour la suite ?
 
   Now we can test parts of our application that we *load* asynchronously with system.js.
 
+  Maintenant nous pouvons tester des parties de nore application que nous *chargeons* de manière asynchrone avec system.js
+
   What about testing parts that *are themselves asynchronous*?
 
+  Mais comment tester des parties qui sont *elles mêmes asynchrones*?
+
   Let's test a service with a public asynchronous method that fetches heroes from a remote server.
+  
+  Allons tester un service avec un méthode asynchrone publique qui récupère des héros depuis un serveur distant.