anchor.diff:  
     然后测试继续运行。
     测试开始另一轮的变化检测（`fixture.detectChanges`）,通知Angular使用名言来更新DOM。
  -  `getQuote`助手方法提取出显示元素文本，然后expect语句确认这个文本与预备的名言相符。
  +  `getQuote`辅助方法提取出显示元素文本，然后expect语句确认这个文本与预备的名言相符。
   
   #fakeAsync
   #fake-async
  
positive.code: #component-with-inputs-outputs
  :marked
    # Test a component with inputs and outputs
    A component with inputs and outputs typically appears inside the view template of a host component.
    The host uses a property binding to set the input property and uses an event binding to
    listen to events raised by the output property.
  
    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 embedded in the `DashboardComponent` template like this:
  +makeExample('testing/ts/app/dashboard/dashboard.component.html', 'dashboard-hero', 'app/dashboard/dashboard.component.html (excerpt)')(format='.')
  :marked
    The `DashboardHeroComponent` appears in an `*ngFor` repeater which sets each component's `hero` input property
    to the iteration value and listens for the components `selected` event.
    
    Here's the component's definition again:
  +makeExample('testing/ts/app/dashboard/dashboard-hero.component.ts', 'component', 'app/dashboard/dashboard-hero.component.ts (component)')(format='.')
  :marked
    While testing a component this simple has little intrinsic value, it's worth knowing how.
    Three approaches come to mind:
    1. Test it as used by `DashboardComponent`
    1. Test it as a stand-alone component
    1. Test it as used by a substitute for `DashboardComponent`
  
    A quick look at the `DashboardComponent` constructor discourages the first approach:
  +makeExample('testing/ts/app/dashboard/dashboard.component.ts', 'ctor', 'app/dashboard/dashboard.component.ts (constructor)')(format='.')
  :marked
    The `DashboardComponent` depends upon the Angular router and the `HeroService`.
    You'd probably have to replace them both with test doubles and that looks like a lot of work. 
    The router seems particularly challenging.
  .l-sub-section
    :marked
      The [discussion below](#routed-component) covers testing components that requre the router.
  :marked
    The immediate goal is to test the `DashboardHeroComponent`, not the `DashboardComponent`, and there's no need
    to work hard unnecessarily. Let's try the second and third options.
  
    ## Test _DashboardHeroComponent_ stand-alone
  
    Here's the spec file setup.
  +makeExample('testing/ts/app/dashboard/dashboard-hero.component.spec.ts', 'setup', 'app/dashboard/dashboard-hero.component.spec.ts (setup)')(format='.')
  
  :marked
  
negative.code: 
    The  Angular testing utilities include the `TestBed` class and several helper functions from `@angular/core/testing`.
  
    **Angular测试工具**包含了`TestBed`类和在`@angular/core/testing`中一些辅助函数方法。
  
    The `TestBed` creates an Angular testing module &mdash; an `@NgModule` class &mdash;
    that you configure to produce the module environment for the class you want to test. 
  