anchor.diff:          The second parameter is the _event object_ expected by the handler.
           See [above](#trigger-event-handler).
   
  +        如果在元素的`listeners`列表中有一个对应的`listener`，则以事件名字触发。
  +        第二个参数是**事件对象**，一般为事件处理器。
  +        参见[上面](#trigger-event-handler)。
  +
           If the event lacks a listener or there's some other problem, 
           consider calling `nativeElement.dispatchEvent(eventObject)`
   
  +        如果事件缺乏监听器，或者有其它问题，考虑调用`nativeElement.dispatchEvent(eventObject)`。
  +
     tr
       td(style="vertical-align: top") <code>listeners</code>
       td
         :marked
           The callbacks attached to the component's `@Output` properties and/or the element's event properties.
  +
  +        元素的`@Output`属性以及/或者元素的事件属性所附带的回调函数。
   
     tr
       td(style="vertical-align: top") <code>providerTokens</code>
  
positive.code:   A few of the `TestBed` instance methods are not covered by static `TestBed` _class_ methods.
    These are rarely needed.
  
  #component-fixture-api-summary
  :marked
    ## The _ComponentFixture_
  
    The `TestBed.createComponent<T>`
    creates an instance of the component `T` 
    and returns a strongly typed `ComponentFixture` for that component.
  
    The `ComponentFixture` properties and methods provide access to the component, 
    its DOM representation, and aspects of its Angular environment. 
  
  #component-fixture-properties
  :marked
    ### _ComponentFixture_ properties
  
    Here are the most important properties for testers, in order of likely utility.
    
  table
    tr
      th Properties
      th Description
    tr
      td(style="vertical-align: top") <code>componentInstance</code>
      td
        :marked
          The instance of the component class created by `TestBed.createComponent`.
    tr
      td(style="vertical-align: top") <code>debugElement</code>
      td
        :marked
          The `DebugElement` associated with the root element of the component.
  
          The `debugElement` provides insight into the component and its DOM element during test and debugging.
          It's a critical property for testers. The most interesting members are covered [below](#debug-element-details).
    tr
      td(style="vertical-align: top") <code>nativeElement</code>
      td
        :marked
          The native DOM element at the root of the component.
    tr
      td(style="vertical-align: top") <code>changeDetectorRef</code>
      td
        :marked
          The `ChangeDetectorRef` for the component.
  
          The `ChangeDetectorRef` is most valuable when testing a
          component that has the `ChangeDetectionStrategy.OnPush`
          or the component's change detection is under your programmatic control.
  
  #component-fixture-methods
  :marked
    ### _ComponentFixture_ methods
  
    The _fixture_ methods cause Angular to perform certain tasks to the component tree.
    Call these method to trigger Angular behavior in response to simulated user action.
  
    Here are the most useful methods for testers.
  table
    tr
      th Methods
      th Description
    tr
      td(style="vertical-align: top") <code>detectChanges</code>
      td
        :marked
          Trigger a change detection cycle for the component.
  
          Call it to initialize the component (it calls `ngOnInit`) and after your 
          test code change the component's data bound property values.
          Angular can't see that you've changed `personComponent.name` and won't update the `name`
          binding until you call `detectChanges`.
  
          Runs `checkNoChanges`afterwards to confirm there are no circular updates unless
          called as `detectChanges(false)`;
    tr
      td(style="vertical-align: top") <code>autoDetectChanges</code>
      td
        :marked
          Set whether the fixture should try to detect changes automatically.
  
          When autodetect is true, the test fixture listens for _zone_ events and calls `detectChanges`. 
          You probably still have to call `fixture.detectChanges` to trigger data binding updates 
          when your test code modifies component property values directly.
  
          The default is `false` and testers who prefer fine control over test behavior
          tend to keep it `false`. 
  
          Calls `detectChanges` immediately which detects existing changes
          and will trigger `ngOnInit` if the component has not yet been initialized.
    tr
      td(style="vertical-align: top") <code>checkNoChanges</code>
      td
        :marked
          Do a change detection run to make sure there are no pending changes.
          Throws an exceptions if there are.
    tr
      td(style="vertical-align: top") <code>isStable</code>
      td
        :marked
          Return `true` if the fixture is currently _stable_.
          Returns `false` if there are async tasks that have not completed.
    tr
      td(style="vertical-align: top") <code>whenStable</code>
      td
        :marked
          Returns a promise that resolves when the fixture is stable.
          
          Hook that promise to resume testing after completion of asynchronous activity or 
          asynchronous change detection.
          See [above](#when-stable)
    tr
      td(style="vertical-align: top") <code>destroy</code>
      td
        :marked
          Trigger component destruction.
  
  #debug-element-details
  :marked
    ### _DebugElement_
  
    The `DebugElement` provides crucial insights into the component's DOM representation.
  
    From the test root component's `DebugElement`, returned by `fixture.debugElement`, 
    you can walk (and query) the fixture's entire element and component sub-trees.
  
    Here are the most useful `DebugElement` members for testers in approximate order of utility.
  
  table
    tr
      th Member
      th Description
    tr
      td(style="vertical-align: top") <code>nativeElement</code>
      td
        :marked
          The corresponding DOM element in the browser (null for WebWorkers).
    tr
      td(style="vertical-align: top") <code>query</code>
      td
        :marked
          Calling `query(predicate: Predicate<DebugElement>)` returns the first `DebugElement`
          that matches the [predicate](#query-predicate) at any depth in the subtree.
    tr
      td(style="vertical-align: top") <code>queryAll</code>
      td
        :marked
          Calling `queryAll(predicate: Predicate<DebugElement>)` returns all `DebugElements`
          that matches the [predicate](#query-predicate) at any depth in subtree.
    tr
      td(style="vertical-align: top") <code>injector</code>
      td
        :marked
          The host dependency injector. 
          For example, the root element's component instance injector.
    tr
      td(style="vertical-align: top") <code>componentInstance</code>
      td
        :marked
          The element's own component instance, if it has one.
     tr
      td(style="vertical-align: top") <code>context</code>
      td
        :marked
          An object that provides parent context for this element.
          Often an ancestor component instance that governs this element.
  
          When an element is repeated with in `*ngFor`, the context is an `NgForRow` whose `$implicit`
          property is the value of the row instance value. 
          For example, the `hero` in `*ngFor="let hero of heroes"`.
    tr
      td(style="vertical-align: top") <code>children</code>
      td
        :marked
          The immediate `DebugElement` children. Walk the tree by descending through `children`.
  
        .l-sub-section
          :marked
            `DebugElement` also has `childNodes`, a list of `DebugNode` objects. 
            `DebugElement` derives from `DebugNode` objects and there are often 
            more nodes than elements. Testers can usually ignore plain nodes.
    tr
      td(style="vertical-align: top") <code>parent</code>
      td
        :marked
          The `DebugElement` parent. Null if this is the root element.
  
    tr
      td(style="vertical-align: top") <code>name</code>
      td
        :marked
          The element tag name, if it is an element.
  
    tr
      td(style="vertical-align: top") <code>triggerEventHandler</code>
  
negative.code: :marked
    ### Why put specs next to the things they test?
  
    ### 为何将测试的spec配置文件放置到被测试文件的傍边？
  
    We recommend putting unit test spec files in the same folder 
    as the application source code files that they test because
    
    我们推荐将单元测试的spec配置文件放到与应用程序源代码文件所在的同一个文件夹中，因为：
  
    - Such tests are easy to find
  
    - 这样的测试很容易被找到 
  
    - You see at a glance if a part of our application lacks tests.
  
    - 你可以一眼看出应用程序的那些部分缺乏测试。
  
    - Nearby tests can reveal how a part works in context.
  
    - 临近的测试可以展示代码是如何在上下文中工作的
  
    - When you move the source (inevitable), you remember to move the test.
  
    - 当你移动代码（无可避免）时，你记得一起移动测试
  
    - When you rename the source file (inevitable), you remember to rename the test file.
  
    - 当你重命名源代码文件（无可避免），你记得重命名测试文件。
  
    
  
  .l-hr
  
  #q-specs-in-test-folder
  :marked
    ### When would I put specs in a test folder?
  
    ### 什么时候我应该把测试spec文件放到测试目录中？
  
    Application integration specs can test the interactions of multiple parts
    spread across folders and modules.
    They don't really belong to part in particular so they don't have a
    natural home next to any one file.
  
    应用程序的整合测试spec文件可以测试横跨多个目录和模块的多个部分之间的互动。
    它们不属于任何部分，很自然，没有特别的地方存放它们。
  
    It's often better to create an appropriate folder for them in the `tests` directory.
  
    通常，在`test`目录中为它们创建一个合适的目录比较好。
  
    Of course specs that test the test helpers belong in the `test` folder,
    next to their corresponding helper files.
  
    当然，用来测试**测试助手对象**的测试spec文件也属于`test`目录，与它们对应的助手文件相邻。
  
  
  