anchor.diff:    The testing goal is to verify that such bindings work as expected. 
     The tests should set input values and listen for output events.
   
  -  The `DashboardHeroComponent` is tiny example of a component in this role.
  -  It displays an individual heroe provided by the `DashboardComponent`. 
  -  Clicking that hero tells the the `DashboardComponent` that the user has selected the hero.
  +  The `DashboardHeroComponent` is a tiny example of a component in this role.
  +  It displays an individual hero provided by the `DashboardComponent`. 
  +  Clicking that hero tells the `DashboardComponent` that the user has selected the hero.
   
     The `DashboardHeroComponent` is embedded in the `DashboardComponent` template like this:
   +makeExample('testing/ts/app/dashboard/dashboard.component.html', 'dashboard-hero', 'app/dashboard/dashboard.component.html (excerpt)')(format='.')
  
positive.code: 
    Fortunately, the `TestBed.configureTestingModule` parameter parallels
    the metadata passed to the `@NgModule` decorator 
    which means you can also specify `providers` and `imports.
  
    The `HeroDetailComponent` requires a lot of help despite its small size and simple construction. 
    In addition to the support it receives from the default testing module `CommonModule`, it needs:
  
negative.code: +makeExample('testing/ts/app/dashboard/dashboard.component.spec.ts', 'router-stub', 'app/dashboard/dashboard.component.spec.ts (Router Stub)')(format='.')
  :marked
    Now we setup the testing module with the test stubs for the `Router` and `HeroService` and 
    create a test instance of the `DashboardComponent` for subsequent testing.
  +makeExample('testing/ts/app/dashboard/dashboard.component.spec.ts', 'compile-and-create-body', 'app/dashboard/dashboard.component.spec.ts (compile and create)')(format='.')
  :marked
    The following test clicks the displayed hero and confirms (with the help of a spy) that `Router.navigateByUrl` is called with the expected url.
  