: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.

.alert.is-important
  :marked
    These testing chapters were written before the Angular 2 Beta release
    and are scheduled for significant updates.
    Much of the material remains accurate and relevant but references to
    specific features of Angular 2 and the Angular 2 testing library
    may not be correct. Please bear with us.
:marked
  Here is what we’ll learn in the unit testing chapters.

  1. Jasmine Testing 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
  
  1. Test a class
    - test a simple application class outside of Angular
    - where to put the test file
    - load a test file with systemJS
  1. Test a Pipe
    - test a simple Angular Pipe class
    - add the Angular 2 library to the  test harness
    - load multiple test files using system.js
  1. Test an Asynchronous Service
    - 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
    - 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
     - 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
    - 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

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