anchor.diff:    There's a twist. The template passes the hero name through the Angular `UpperCasePipe` so the
     test must match the element value with the uppercased name:
   
  -  它验证了英雄名字通过绑定被传递到模板了。这里有个意外曲折。模板将英雄名字传给Angular的`UpperCasePipe`，
  +  它验证了英雄名字通过绑定被传递到模板了。这里有个额外步骤。模板将英雄名字传给Angular的`UpperCasePipe`，
     所以测试必须使用大写名字来匹配元素的值：
   +makeExample('testing/ts/app/dashboard/dashboard-hero.component.html')(format='.')
   :marked
  
positive.code: :marked
    # Test a component inside a test host component
  
    In the previous approach the tests themselves played the role of the host `DashboardComponent`.
    A nagging suspicion remains. 
    Will the `DashboardHeroComponent` work properly when properly data-bound to a host component? 
  
    Testing with the actual `DashboardComponent` host is doable but seems more trouble than its worth.
    It's easier to emulate the `DashboardComponent` host with a _test host_ like this one:
  +makeExample('testing/ts/app/dashboard/dashboard-hero.component.spec.ts', 'test-host', 'app/dashboard/dashboard-hero.component.spec.ts (test host)')(format='.')
  :marked
    The test host binds to `DashboardHeroComponent` as the `DashboardComponent` would but without
    the distraction of the `Router`, the `HeroService` or even the `*ngFor` repeater.
  
    The test host sets the component's `hero` input property with its test hero.
    It binds the component's `selected` event with its `onSelected` handler that records the emitted hero
    in its `selectedHero` property. Later the tests check that property to verify that the
    `DashboardHeroComponent.selected` event really did emit the right hero.
  
    The setup for the test-host tests is similar to the setup for the stand-alone tests:
  +makeExample('testing/ts/app/dashboard/dashboard-hero.component.spec.ts', 'test-host-setup', 'app/dashboard/dashboard-hero.component.spec.ts (test host setup)')(format='.')
  :marked
    This testing module configuration shows two important differences:
    1. It _declares_ both the `DashboardHeroComponent` and the `TestHostComponent`.
    1. It _creates_ the `TestHostComponent` instead of the `DashboardHeroComponent`.
  
    The `fixture` returned by `createComponent` holds an instance of `TestHostComponent` instead of an instance of `DashboardHeroComponent`.
    
    Of course creating the `TestHostComponent` has the side-effect of creating a `DashboardHeroComponent`
    because the latter appears within the template of the former. 
    The query for the hero element (`heroEl`) still finds it in the test DOM 
    albeit at greater depth in the element tree than before.
    
    The tests themselves are almost identical to the stand-alone version
  +makeExample('testing/ts/app/dashboard/dashboard-hero.component.spec.ts', 'test-host-tests', 'app/dashboard/dashboard-hero.component.spec.ts (test-host)')(format='.')
  :marked
    Only the selected event test differs. It confirms that the selected `DashboardHeroComponent` hero
    really does find its way up through the event binding to the host component.
  
  a(href="#top").to-top Back to top
  
  .l-hr
  
  
negative.code:   Note how the setup code assigns a test hero (`expectedHero`) to the component's `hero` property, emulating
    the way the `DashboardComponent` would set it via the property binding in its repeater.
  
    注意代码是如何将一个模拟英雄（`expectedHero`）赋值给组件的`hero`属性的，模拟了`DashbaordComponent`在它的迭代器中通过属性绑定的赋值方式。
  
    The first test follows:
  
  