anchor.diff:      It works hard to appear useful when in fact it 
       tests the `RouterLinkStubDirective` rather than the _component_.
       This is a common failing of directive stubs.
  +
  +    本例中的“click”测试其实毫无价值。
  +    它显得很有用，但是事实上，它测试的是`RouterLinkStubDirective`，而非测试组件。
  +    这是指令stub的通病。
       
       It has a legitimate purpose in this chapter. 
       It demonstrates how to find a `RouterLink` element, click it, and inspect a result,
  
positive.code:   自己探索这些选项和组合。
  
  a(href="#top").to-top Back to top
  a(href="#top").to-top 返回顶部
  .l-hr
  
  #router-outlet-component
  
negative.code:   For example, a navigation guard could prevent an unauthorized user from visiting the `HeroListComponent`.
    That's not the fault of the `AppComponent` and no change to that component could cure the failed test.
  
    对于这样局限的测试目标，stub伪造RouterLink和RouterOutlet是最佳选择。
    依靠真正的路由器会让它们很脆弱。
    它们可能因为与组件无关的原因而失败。
    例如，一个导航守卫可能防止没有授权的用户访问`HeroListComponent`。
    这并不是`AppComponent`的过错，并且无论该组件怎么改变都无法修复这个失败的测试。
  
    A _different_ battery of tests can explore whether the application navigates as expected
    in the presence of conditions that influence guards such as whether the user is authenticated and authorized.
    A future chapter update will explain how to write such tests with the `RouterTestingModule`.
  
    不同的测试可以探索在不同条件下，比如像检查用户是否认证这样的守卫下，该应用是否和期望的那样导航。
    未来本章的更新将介绍如何使用`RouterTestingModule`来编写这样的测试。
  a(href="#top").to-top Back to top
  a(href="#top").to-top 回到顶部
  .l-hr
  
  #shallow-component-test
  :marked
    # "Shallow component tests" with *NO\_ERRORS\_SCHEMA*
    # 使用*NO\_ERRORS\_SCHEMA*来“浅化”组件测试
  
    The [previous setup](#stub-component) declared the `BannerComponent` and stubbed two other components 
    for _no reason other than to avoid a compiler error_.
  
    [以前的配置](#stub-component)声明了`BannerComponent`，并stub伪造了两个其它组件，**仅仅是为了避免编译错误，不是为别的原因**。
    
    Without them, the Angular compiler doesn't recognize the `<app-banner>`, `<app-welcome>` and `<router-outlet>` tags 
    in the [_app.component.html_](#app-component-html) template and throws an error. 
  
    没有它们，Angular编译器无法识别[_app.component.html_](#app-component-html)模板里的`<app-banner>`、`<app-welcome>`和`<router-outlet>`标签，并抛出错误。
  
    Add `NO_ERRORS_SCHEMA` to the testing module's `schemas` metadata
    to tell the compiler to ignore unrecognized elements and attributes.
    You no longer have to declare irrelevant components and directives.
  
    添加`NO_ERRORS_SCHEMA`到测试模块的`schemas`元数据中，告诉编译器忽略不认识的元素和属性。
    这样你不再需要声明无关组件和指令。
    
    These tests are ***shallow*** because they only "go deep" into the components you want to test.
    Here is a setup (with `import` statements) that demonstrates the improved simplicity of _shallow_ tests, relative to the stubbing setup.
  
    这些测试比较**浅**，因为它们只“深入”到你要测试的组件。
    这里是一套配置（拥有`import`语句），演示了相比使用stub伪造的配置来说，**浅**测试的简单性。
  +makeTabs('testing/ts/app/app.component.spec.ts, testing/ts/app/app.component.spec.ts', 
    'setup-schemas, setup-stubs-w-imports', 
    'app/app.component.spec.ts (NO_ERRORS_SCHEMA), app/app.component.spec.ts (Stubs)')(format='.')
  