:marked
  We write **unit tests** to explore and confirm the **behavior** of parts of our application.

  1. They **guard** against breaking existing code (“regressions”) when we make changes.
  1. They **clarify** what  the code does both when used as intended and when faced with deviant conditions.
  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.
    
a(id="top")
:marked
  # Table of Contents

  1. [Jasmine Testing 101](#jasmine-101)
    - setup to run Jasmine tests in the browser
    - basic Jasmine testing skills
    - write simple Jasmine tests in TypeScript
    - debug a test in the browser
  
  1. [The Application Under Test](#aut)
  
  1. [First app test](#first-app-tests)
    - test a simple application interface outside of Angular
    - where to put the test file
    - load a test file with systemJS
  
  1. [Pipe driven development](#pipe-testing)
    - create a test before creating a class
    - load multiple test files in our test harness, using system.js
    - add the Angular 2 library to our test harness
    - watch the new test fail, and fix it
  
  1. Test an Asynchronous Service (forthcoming)
    - test an asynchronous service class outside of Angular
    - write a test plan in code
    - fake a dependency
    - master the `catch(fail).then(done)` pattern
    - move setup to `beforeEach`
    - test when a dependency fails
    - control async test timeout
  
  1. The Angular Test Environment (forthcoming)
    - the Angular test environment and why we need help
    - add the Angular Test libraries to the  test harness
    - test the same async service using Angular Dependency Injection
    - reduce friction with test helpers
    - introducing spies
  
  1. Test a Component (forthcoming)
     - test the component outside of Angular
    - mock the dependent asynchronous service
    - simulate interaction with the view (no DOM)
    - use a spy-promise to control asynchronous test flow
  
  1. Test a Component in the DOM (forthcoming
    - test the component inside the Angular test environment
    - use the `TestComponentBuilder`
    - more test helpers
    - interact with the DOM
    - bind to a mock dependent asynchronous service
  
  1. Run the tests with karma (forthcoming)

  It’s a big agenda. Fortunately, you can learn a little bit at a time and put each lesson to use.

a(href="#top").to-top Back to top

.l-hr
a(id="jasmine-101")
:marked
  # Jasmine Testing 101
!= partial("../testing/jasmine-testing-101")
a(href="#top").to-top Back to top

.l-hr
a(id="aut")
:marked
  # The Application to Test
!= partial("../testing/application-under-test")
a(href="#top").to-top Back to top

.l-hr
a(id="first-app-tests")
:marked
  # First app test
!= partial("../testing/first-app-tests")
a(href="#top").to-top Back to top

.l-hr
a(id="pipe-testing")
:marked
  # Pipe driven development
!= partial("../testing/testing-an-angular-pipe")
a(href="#top").to-top Back to top

.alert.is-important
  :marked
    The testing chapter is still under development.
    Please bear with us as we both update and complete it.