Technology 技术	Purpose 目的
Jasmine	The [Jasmine test framework](http://jasmine.github.io/2.4/introduction.html) provides everything needed to write basic tests. It ships with an HTML test runner that executes tests in the browser. [Jasmine测试框架](http://jasmine.github.io/2.4/introduction.html)提供了所有编写基本测试的工具。它自带HTML测试运行器，用来在浏览器中执行测试程序。
Angular testing utilities Angular测试工具	Angular testing utilities create a test environment for the Angular application code under test. Use them to condition and control parts of the application as they interact _within_ the Angular environment. Angular测试工具为被测试的Angular应用代码创建测试环境。在应用代码与Angular环境互动时，使用Angular测试工具来限制和控制应用的部分代码。
Karma	The [karma test runner](https://karma-runner.github.io/1.0/index.html) is ideal for writing and running unit tests while developing the application. It can be an integral part of the project's development and continuous integration processes. This guide describes how to set up and run tests with karma. [karma测试运行器](https://karma-runner.github.io/1.0/index.html)是在开发应用的过程中编写和运行单元测试的理想工具。它能成为项目开发和连续一体化进程的不可分割的一部分。本章讲述了如何用Karma设置和运行测试程序。
Protractor	Use protractor to write and run _end-to-end_ (e2e) tests. End-to-end tests explore the application _as users experience it_. In e2e testing, one process runs the real application and a second process runs protractor tests that simulate user behavior and assert that the application respond in the browser as expected. 使用`Protractor`来编写和运行_端对端(e2e)_测试程序。端对端测试程序像用户体验应用程序那样探索它。在端对端测试中，一条进程运行真正的应用，另一条进程运行Protractor测试程序，模拟用户行为，判断应用在浏览器中的反应是否正确。

Technology

技术

Purpose

目的

Jasmine

The [Jasmine test framework](http://jasmine.github.io/2.4/introduction.html) provides everything needed to write basic tests. It ships with an HTML test runner that executes tests in the browser. [Jasmine测试框架](http://jasmine.github.io/2.4/introduction.html)提供了所有编写基本测试的工具。它自带HTML测试运行器，用来在浏览器中执行测试程序。

Angular testing utilities

Angular测试工具

Angular testing utilities create a test environment for the Angular application code under test. Use them to condition and control parts of the application as they interact _within_ the Angular environment. Angular测试工具为被测试的Angular应用代码创建测试环境。在应用代码与Angular环境互动时，使用Angular测试工具来限制和控制应用的部分代码。

Karma

The [karma test runner](https://karma-runner.github.io/1.0/index.html) is ideal for writing and running unit tests while developing the application. It can be an integral part of the project's development and continuous integration processes. This guide describes how to set up and run tests with karma. [karma测试运行器](https://karma-runner.github.io/1.0/index.html)是在开发应用的过程中编写和运行单元测试的理想工具。它能成为项目开发和连续一体化进程的不可分割的一部分。本章讲述了如何用Karma设置和运行测试程序。

Protractor

Use protractor to write and run _end-to-end_ (e2e) tests. End-to-end tests explore the application _as users experience it_. In e2e testing, one process runs the real application and a second process runs protractor tests that simulate user behavior and assert that the application respond in the browser as expected. 使用`Protractor`来编写和运行_端对端(e2e)_测试程序。端对端测试程序**像用户体验应用程序那样**探索它。在端对端测试中，一条进程运行真正的应用，另一条进程运行Protractor测试程序，模拟用户行为，判断应用在浏览器中的反应是否正确。

`. The test calls `triggerEventHandler` with the "click" event name. The "click" event binding responds by calling `DashboardHeroComponent.click()`. `heroEl`是个`DebugElement`，它代表了英雄所在的`

`。测试程序用“click”事件名字来调用`triggerEventHandler`。调用`DashboardHeroComponent.click()`时，“click”事件绑定作出响应。 If the component behaves as expected, `click()` tells the component's `selected` property to emit the `hero` object, the test detects that value through its subscription to `selected`, and the test should pass. 如果组件像期待的那样工作，`click()`通知组件的`selected`属性就会发出`hero`对象，测试程序通过订阅`selected`事件而检测到这个值，所以测试应该成功。 {@a trigger-event-handler} ### _triggerEventHandler_ The Angular `DebugElement.triggerEventHandler` can raise _any data-bound event_ by its _event name_. The second parameter is the event object passed to the handler. Angular的`DebugElement.triggerEventHandler`可以用**事件的名字**触发**任何数据绑定事件**。第二个参数是传递给事件处理器的事件对象。 In this example, the test triggers a "click" event with a null event object. 本例中，测试程序用null事件对象触发“click”事件。 The test assumes (correctly in this case) that the runtime event handler—the component's `click()` method—doesn't care about the event object. 测试程序假设（在这里应该这样)运行时间的事件处理器——组件的`click()`方法——不关心事件对象。 Other handlers are less forgiving. For example, the `RouterLink` directive expects an object with a `button` property that identifies which mouse button was pressed. This directive throws an error if the event object doesn't do this correctly. 其它处理器将会更加严格。比如，`RouterLink`指令期待事件对象，并且该对象具有`button`属性，代表了已被按下的鼠标按钮。如果该事件对象不具备上面的条件，指令便会抛出错误。 {@a click-helper} Clicking a button, an anchor, or an arbitrary HTML element is a common test task. 点击按钮、链接或者任意HTML元素是很常见的测试任务。 Make that easy by encapsulating the _click-triggering_ process in a helper such as the `click` function below: 把**click触发**过程封装到辅助方法中可以简化这个任务，比如下面的`click`辅助方法： The first parameter is the _element-to-click_. If you wish, you can pass a custom event object as the second parameter. The default is a (partial) left-button mouse event object accepted by many handlers including the `RouterLink` directive. 第一个参数是**用来点击的元素**。如果你愿意，可以将自定义的事件对象传递给第二个参数。默认的是（局部的）鼠标左键事件对象，它被许多事件处理器接受，包括`RouterLink`指令。

click() is not an Angular testing utility

click()不是Angular测试工具

The `click()` helper function is **not** one of the Angular testing utilities. It's a function defined in _this guide's sample code_. All of the sample tests use it. If you like it, add it to your own collection of helpers. `click()`辅助函数**不是**Angular测试工具之一。它是在**本章的例子代码**中定义的函数方法，被所有测试例子所用。如果你喜欢它，将它添加到你自己的辅助函数集。

Here's the previous test, rewritten using this click helper. 下面是使用了click辅助函数重新编写的上一个测试程序：

{@a component-inside-test-host} ## Test a component inside a test host component ## 在测试宿主组件中测试组件 # 在测试宿主组件中测试组件 In the previous approach, the tests themselves played the role of the host `DashboardComponent`. But does the `DashboardHeroComponent` work correctly when properly data-bound to a host component? 在前面的方法中，测试本身扮演了宿主组件`DashbaordComponent`的角色。一种挥之不去的疑虑仍然存在：当正常数据绑定到宿主组件时，`DashboardHeroComponent`还会正常工作吗？ 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: 使用实际的`DashbaordComponent`宿主来测试是可行的，但是这么做似乎不合算。像下面这样使用**测试宿主组件**来模拟`DashbaordComponent`显得更加容易： The test host binds to `DashboardHeroComponent` as the `DashboardComponent` would but without the distraction of the `Router`, the `HeroService`, or even the `*ngFor` repeater. 测试宿主组件和`DashboardComponent`一样绑定`DashboardHeroComponent`，但是不用理会`Router`、`HeroService`服务，甚至`*ngFor`循环。 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, which records the emitted hero in its `selectedHero` property. Later, the tests check that property to verify that the `DashboardHeroComponent.selected` event emitted the right hero. 测试宿主将组件的`hero`导入属性设置为它的模拟英雄。它将组件的`selected`事件绑定到它的`onSelected`处理器，使用`selectedHero`属性来记录发送来的英雄。然后测试检查这个属性来验证`DashboardHeroComponent.selected`事件确实发送了正确的英雄。 The setup for the test-host tests is similar to the setup for the stand-alone tests: 配置使用测试宿主的测试程序与配置孤立测试相似： This testing module configuration shows two important differences: 这个测试模块配置展示了两个非常重要的区别： 1. It _declares_ both the `DashboardHeroComponent` and the `TestHostComponent`. 它同时**声明**了`DashboardHeroComponent`和`TestHostComponent`。 1. It _creates_ the `TestHostComponent` instead of the `DashboardHeroComponent`. 它**创建**了`TestHostComponent`，而非`DashboardHeroComponent`。 The `createComponent` returns a `fixture` that holds an instance of `TestHostComponent` instead of an instance of `DashboardHeroComponent`. `createComponent`返回的`fixture`里有`TestHostComponent`实例，而非`DashboardHeroComponent`组件实例。 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. 当然，创建`TestHostComponent`有创建`DashboardHeroComponent`的副作用，因为后者出现在前者的模板中。英雄元素（`heroEl`)的查询语句仍然可以在测试DOM中找到它，尽管元素树比以前更深。 The tests themselves are almost identical to the stand-alone version: 这些测试本身和它们的孤立版本几乎相同： 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. 只有selected事件的测试不一样。它确保被选择的`DashboardHeroComponent`英雄确实通过事件绑定被传递到宿主组件。 Back to top 回到顶部

{@a routed-component} ## Test a routed component ## 测试带路由器的组件 Testing the actual `DashboardComponent` seemed daunting because it injects the `Router`. 测试实际的`DashbaordComponent`似乎令人生畏，因为它注入了`Router`。 It also injects the `HeroService`, but faking that is a [familiar story](guide/testing#component-with-async-service). The `Router` has a complicated API and is entwined with other services and application preconditions. 它同时还注入了`HeroService`，但是我们已经知道如何[伪造](guide/testing#component-with-async-servic)它。 `Router`的API非常复杂，并且它缠绕了其它服务和许多应用的先决条件。 Fortunately, the `DashboardComponent` isn't doing much with the `Router` 幸运的是，`DashbaordComponent`没有使用`Router`做很多事情。 This is often the case. As a rule you test the component, not the router, and care only if the component navigates with the right address under the given conditions. Stubbing the router with a test implementation is an easy option. This should do the trick: 通常都是这样的。原则上，你测试的是组件，不是路由器，应该只关心在指定的条件下，组件是否导航到正确的地址。用模拟类来替换路由器是一种简单的方案。下面的代码应该可以： Now set up the testing module with the test stubs for the `Router` and `HeroService`, and create a test instance of the `DashboardComponent` for subsequent testing. 现在我们来利用`Router`和`HeroService`的测试stub类来配置测试模块，并为接下来的测试创建`DashboardComponent`的测试实例。 The following test clicks the displayed hero and confirms (with the help of a spy) that `Router.navigateByUrl` is called with the expected url. 下面的测试程序点击显示的英雄，并利用spy来确认`Router.navigateByUrl`被调用了，而且传进的url是所期待的值。 {@a inject} ### The _inject_ function ### _inject_函数 Notice the `inject` function in the second `it` argument. 注意第二个`it`参数里面的`inject`函数。 The `inject` function is one of the Angular testing utilities. It injects services into the test function where you can alter, spy on, and manipulate them. `inject`函数是Angular测试工具之一。它注入服务到测试函数，以供修改、监视和操纵。 The `inject` function has two parameters: `inject`函数有两个参数： 1. An array of Angular dependency injection tokens. 一列数组，包含了Angular依赖注入令牌 1. A test function whose parameters correspond exactly to each item in the injection token array. 一个测试函数，它的参数与注入令牌数组里的每个项目严格的一一对应。

inject uses the TestBed Injector

使用TestBed注入器来注入

The `inject` function uses the current `TestBed` injector and can only return services provided at that level. It does not return services from component providers. `inject`函数使用当前`TestBed`注入器，并且只返回这个级别提供的服务。它不会返回组件提供商提供的服务。

This example injects the `Router` from the current `TestBed` injector. That's fine for this test because the `Router` is, and must be, provided by the application root injector. 这个例子通过当前的`TestBed`注入器来注入`Router`。对这个测试程序来说，这是没问题的，因为`Router`是（也必须是）由应用的根注入器来提供。 If you need a service provided by the component's _own_ injector, call `fixture.debugElement.injector.get` instead: 如果你需要组件自己的注入器提供的服务，调用`fixture.debugElement.injector.get`：

Use the component's own injector to get the service actually injected into the component. 使用组件自己的注入器来获取实际注入到组件的服务。

The `inject` function closes the current `TestBed` instance to further configuration. You cannot call any more `TestBed` configuration methods, not `configureTestingModule` nor any of the `override...` methods. The `TestBed` throws an error if you try. `inject`函数关闭当前`TestBed`实例，使它无法再被配置。你不能再调用任何`TestBed`配置方法、`configureTestModule`或者任何`override...`方法，否则`TestBed`将抛出错误。

Do not configure the `TestBed` after calling `inject`. 不要在调用`inject`以后再试图配置`TestBed`。

Back to top 回到顶部 {@a routed-component-w-param} ### Test a routed component with parameters ### 测试带有路由和路由参数的组件 Clicking a _Dashboard_ hero triggers navigation to `heroes/:id`, where `:id` is a route parameter whose value is the `id` of the hero to edit. That URL matches a route to the `HeroDetailComponent`. 点击**Dashboard**英雄触发导航到`heros/:id`，其中`:id`是路由参数，它的值是进行编辑的英雄的`id`。这个URL匹配到`HeroDetailComponent`的路由。 The router pushes the `:id` token value into the `ActivatedRoute.params` _Observable_ property, Angular injects the `ActivatedRoute` into the `HeroDetailComponent`, and the component extracts the `id` so it can fetch the corresponding hero via the `HeroDetailService`. Here's the `HeroDetailComponent` constructor: 路由器将`:id`令牌的值推送到`ActivatedRoute.params`**可观察**属性里， Angular注入`ActivatedRoute`到`HeroDetailComponent`中，然后组件提取`id`，这样它就可以通过`HeroDetailService`获取相应的英雄。下面是`HeroDetailComponent`的构造函数： `HeroDetailComponent` subscribes to `ActivatedRoute.params` changes in its `ngOnInit` method. `HeroDetailComponent`在它的`ngOnInit`方法中监听`ActivatedRoute.params`的变化。

The expression after `route.params` chains an _Observable_ operator that _plucks_ the `id` from the `params` and then chains a `forEach` operator to subscribe to `id`-changing events. The `id` changes every time the user navigates to a different hero. `route.params`之后的表达式链接了**可观察**操作符，它从`params`中提取`id`，然后链接`forEach`操作符来订阅`id`变化事件。每次`id`变化时，用户被导航到不同的英雄。 The `forEach` passes the new `id` value to the component's `getHero` method (not shown) which fetches a hero and sets the component's `hero` property. If the`id` parameter is missing, the `pluck` operator fails and the `catch` treats failure as a request to edit a new hero. `forEach`将新的`id`值传递到组件的`getHero`方法（这里没有列出来），它获取英雄并将它赋值到组件的`hero`属性。如果`id`参数无效，`pluck`操作符就会失败，`catch`将失败当作创建新英雄来处理。 The [Router](guide/router#route-parameters) guide covers `ActivatedRoute.params` in more detail. [路由器](guide/router#route-parameters)章更详尽的讲述了`ActivatedRoute.params`。

A test can explore how the `HeroDetailComponent` responds to different `id` parameter values by manipulating the `ActivatedRoute` injected into the component's constructor. 通过操纵被注入到组件构造函数的`ActivatedRoute`服务，测试程序可以探索`HeroDetailComponent`是如何对不同的`id`参数值作出响应的。 By now you know how to stub the `Router` and a data service. Stubbing the `ActivatedRoute` follows the same pattern except for a complication: the `ActivatedRoute.params` is an _Observable_. 现在，你已经知道如何模拟`Router`和数据服务。模拟`ActivatedRoute`遵循类似的模式，但是有个额外枝节：`ActivatedRoute.params`是**可观察对象**。 {@a stub-observable} ### Create an _Observable_ test double ### **可观察对象**的测试替身 The `hero-detail.component.spec.ts` relies on an `ActivatedRouteStub` to set `ActivatedRoute.params` values for each test. This is a cross-application, re-usable _test helper class_. Consider placing such helpers in a `testing` folder sibling to the `app` folder. This sample keeps `ActivatedRouteStub` in `testing/router-stubs.ts`: `hero-detail.component.spec.ts`依赖`ActivatedRouteStub`来为每个测试程序设置`ActivatedRoute.params`值。它是跨应用、可复用的**测试辅助类**。我们建议将这样的辅助类放到`app`目录下的名为`testing`的目录。本例把`ActivatedRouteStub`放到`testing/router-stubs.ts`： Notable features of this stub are: 这个stub类有下列值得注意的特征： * The stub implements only two of the `ActivatedRoute` capabilities: `params` and `snapshot.params`. 这个stub类只实现`ActivatedRoute`的两个功能：`params`和`snapshot.params`。 * _BehaviorSubject_ drives the stub's `params` _Observable_ and returns the same value to every `params` subscriber until it's given a new value. _BehaviorSubject_驱使这个stub类的`params`可观察对象，并为每个`params`的订阅者返回同样的值，直到它接受到新值。 * The `HeroDetailComponent` chains its expressions to this stub `params` _Observable_ which is now under the tester's control. `HeroDetailComponent`链接它的表达式到这个stub类的`params`可观察对象，该对象现在被测试者的控制之下。 * Setting the `testParams` property causes the `subject` to push the assigned value into `params`. That triggers the `HeroDetailComponent` _params_ subscription, described above, in the same way that navigation does. 设置`testParams`属性导致`subject`将指定的值推送进`params`。它触发上面描述过的`HeroDetailComponent`的`params`订阅，和导航的方式一样。 * Setting the `testParams` property also updates the stub's internal value for the `snapshot` property to return. 设置`testParams`属性同时更新这个stub类内部值，用于`snapshot`属性的返回。

The [_snapshot_](guide/router#snapshot "Router guide: snapshot") is another popular way for components to consume route parameters. [_snapshot_](guide/router#snapshot "Router Chapter: snapshot")是组件使用路由参数的另一种流行的方法。

The router stubs in this guide are meant to inspire you. Create your own stubs to fit your testing needs. 本章的路由器stub类是为了给你灵感。创建你自己的stub类，以适合你的测试需求。

{@a tests-w-observable-double} ### Testing with the _Observable_ test double ### 测试**可观察对象**的替身 Here's a test demonstrating the component's behavior when the observed `id` refers to an existing hero: 下面的测试程序是演示组件在被观察的`id`指向现有英雄时的行为：

The `createComponent` method and `page` object are discussed [in the next section](guide/testing#page-object). Rely on your intuition for now. [下一节](guide/testing#page-object)将解释`createComponent`方法和`page`对象，现在暂时跟着自己的直觉走。

When the `id` cannot be found, the component should re-route to the `HeroListComponent`. The test suite setup provided the same `RouterStub` [described above](guide/testing#routed-component) which spies on the router without actually navigating. This test supplies a "bad" id and expects the component to try to navigate. 当无法找到`id`时，组件应该重新导航到`HeroListComponent`。该测试套件配置与[上面描述](guide/testing#routed-component)的`RouterStub`一样，它在不实际导航的情况下刺探路由器。该测试程序提供了“坏”的id，期望组件尝试导航。 While this app doesn't have a route to the `HeroDetailComponent` that omits the `id` parameter, it might add such a route someday. The component should do something reasonable when there is no `id`. 虽然本应用没有在缺少`id`参数的时候，继续导航到`HeroDetailComponent`的路由，但是，将来它可能会添加这样的路由。当没有`id`时，该组件应该作出合理的反应。 In this implementation, the component should create and display a new hero. New heroes have `id=0` and a blank `name`. This test confirms that the component behaves as expected: 在本例中，组件应该创建和显示新英雄。新英雄的`id`为零，`name`为空。本测试程序确认组件是按照预期的这样做的：

Inspect and download _all_ of the guide's application test code with this live example. 到在线例子查看和下载**所有**本章应用程序测试代码。

{@a page-object} ## Use a _page_ object to simplify setup ## 使用**page**对象来简化配置 The `HeroDetailComponent` is a simple view with a title, two hero fields, and two buttons. `HeroDetailComponent`是带有标题、两个英雄字段和两个按钮的简单视图。

But there's already plenty of template complexity. 但是它已经有很多模板复杂性。 To fully exercise the component, the test needs a lot of setup: 要彻底测试该组件，测试程序需要一系列设置： * It must wait until a hero arrives before `*ngIf` allows any element in DOM. 它必须在`*ngIf`允许元素进入DOM之前，等待`hero`的到来 * It needs references to the title `` and the name `` so it can inspect their values. 它需要标题名字span和名字输入框元素的引用，用来检查它们的值 * It needs references to the two buttons so it can click them. 它需要两个按钮的引用，以便点击它们 * It needs spies for some of the component and router methods. 刺探（spy）组件和路由器的方法 Even a small form such as this one can produce a mess of tortured conditional setup and CSS element selection. 即使是像这样一个很小的表单，也能产生令人疯狂的错综复杂的条件设置和CSS元素选择。 Tame the madness with a `Page` class that simplifies access to component properties and encapsulates the logic that sets them. Here's the `Page` class for the `hero-detail.component.spec.ts` 通过简化组件属性的访问和封装设置属性的逻辑，`Page`类可以轻松解决这个令人抓狂的难题。下面是为`hero-detail.component.spec.ts`准备的`page`类： Now the important hooks for component manipulation and inspection are neatly organized and accessible from an instance of `Page`. 现在，用来操作和检查组件的重要钩子都被井然有序的组织起来了，可以通过`page`实例来使用它们。 A `createComponent` method creates a `page` objectand fills in the blanks once the `hero` arrives. `createComponent`方法创建`page`，在`hero`到来时，自动填补空白。 The [observable tests](guide/testing#tests-w-observable-double) in the previous section demonstrate how `createComponent` and `page` keep the tests short and _on message_. There are no distractions: no waiting for promises to resolve and no searching the DOM for element values to compare. 上一节的[可观察对象测试](guide/testing#tests-w-observable-double)展示了`createComponent`和`page`如何让测试程序简短和即时。没有任何干扰：无需等待承诺的解析，也没有搜索DOM元素值进行比较。 Here are a few more `HeroDetailComponent` tests to drive the point home. 这里是一些更多的`HeroDetailComponent`测试程序，进一步的展示了这一点。 Back to top 回到顶部

{@a import-module} ## Setup with module imports ## 模块导入imports的配置 Earlier component tests configured the testing module with a few `declarations` like this: 此前的组件测试程序使用了一些`declarations`来配置模块，就像这样： The `DashboardComponent` is simple. It needs no help. But more complex components often depend on other components, directives, pipes, and providers and these must be added to the testing module too. `DashbaordComponent`非常简单。它不需要帮助。但是更加复杂的组件通常依赖其它组件、指令、管道和提供商，所以这些必须也被添加到测试模块中。 Fortunately, the `TestBed.configureTestingModule` parameter parallels the metadata passed to the `@NgModule` decorator which means you can also specify `providers` and `imports`. 幸运的是，`TestBed.configureTestingModule`参数与传入`@NgModule`装饰器的元数据一样，也就是所你也可以指定`providers`和`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: 虽然`HeroDetailComponent`很小，结构也很简单，但是它需要很多帮助。除了从默认测试模块`CommonModule`中获得的支持，它还需要： * `NgModel` and friends in the `FormsModule` to enable two-way data binding. `FormsModule`里的`NgModel`和其它，来进行双向数据绑定 * The `TitleCasePipe` from the `shared` folder. `shared`目录里的`TitleCasePipe` * Router services (which these tests are stubbing). 一些路由器服务（测试程序将stub伪造它们） * Hero data access services (also stubbed). 英雄数据访问服务（同样被stub伪造了） One approach is to configure the testing module from the individual pieces as in this example: 一种方法是在测试模块中一一配置，就像这样： Because many app components need the `FormsModule` and the `TitleCasePipe`, the developer created a `SharedModule` to combine these and other frequently requested parts. The test configuration can use the `SharedModule` too as seen in this alternative setup: 因为许多应用组件需要`FormsModule`和`TitleCasePipe`，所以开发者创建了`SharedModule`来合并它们和一些频繁需要的部件。测试配置也可以使用`SharedModule`，请看下面另一种配置： It's a bit tighter and smaller, with fewer import statements (not shown). 它的导入声明少一些（未显示），稍微干净一些，小一些。 {@a feature-module-import} ### Import the feature module ### 导入特性模块 The `HeroDetailComponent` is part of the `HeroModule` [Feature Module](guide/ngmodule#feature-modules) that aggregates more of the interdependent pieces including the `SharedModule`. Try a test configuration that imports the `HeroModule` like this one: `HeroDetailComponent`是`HeroModule`[特性模块](guide/ngmodule#feature-modules)的一部分，它组合了更多互相依赖的部件，包括`SharedModule`。试试下面这个导入`HeroModule`的测试配置： That's _really_ crisp. Only the _test doubles_ in the `providers` remain. Even the `HeroDetailComponent` declaration is gone. 这样特别清爽。只有`providers`里面的测试替身被保留。连`HeroDetailComponent`声明都消失了。

In fact, if you try to declare it, Angular throws an error because `HeroDetailComponent` is declared in both the `HeroModule` and the `DynamicTestModule` (the testing module). 事实上，如果里试图声明它，Angular会抛出错误，因为`HeroDetailComponent`已经在`HeroModule`和测试模块的`DynamicTestModule`中声明。

Importing the component's feature module is often the easiest way to configure the tests, especially when the feature module is small and mostly self-contained, as feature modules should be. 导入组件的特性模块通常是最简单的配置测试的方法，尤其是当特性模块很小而且几乎自包含时...特性模块应该是自包含的。

{@a component-override} ## Override a component's providers ## 重载组件的提供商 The `HeroDetailComponent` provides its own `HeroDetailService`. `HeroDetailComponent`提供自己的`HeroDetailService`服务。 It's not possible to stub the component's `HeroDetailService` in the `providers` of the `TestBed.configureTestingModule`. Those are providers for the _testing module_, not the component. They prepare the dependency injector at the _fixture level_. 在`TestBed.configureTestingModule`的`providers`中stub伪造组件的`HeroDetailService`是不可行的。这些是**测试模块**的提供商，而非组件的。组件级别的供应商应该在**fixture级别**准备的依赖注入器。 Angular creates the component with its _own_ injector, which is a _child_ of the fixture injector. It registers the component's providers (the `HeroDetailService` in this case) with the child injector. A test cannot get to child injector services from the fixture injector. And `TestBed.configureTestingModule` can't configure them either. Angular创建组件时，该组件有自己的注入器，它是fixture注入器的子级。 Angular使用这个子级注入器来注册组件的提供商（也就是`HeroDetailService`）。测试程序无法从fixture的注入器获取这个子级注入器。而且`TestBed.configureTestingModule`也无法配置它们。 Angular has been creating new instances of the real `HeroDetailService` all along! Angular始终都在创建真实`HeroDetailService`的实例。

These tests could fail or timeout if the `HeroDetailService` made its own XHR calls to a remote server. There might not be a remote server to call. 如果`HeroDetailService`向远程服务器发出自己的XHR请求，这些测试可能会失败或者超时。这个远程服务器可能根本不存在。 Fortunately, the `HeroDetailService` delegates responsibility for remote data access to an injected `HeroService`. 幸运的是，`HeroDetailService`将远程数据访问的责任交给了注入进来的`HeroService`。 The [previous test configuration](guide/testing#feature-module-import) replaces the real `HeroService` with a `FakeHeroService` that intercepts server requests and fakes their responses. [之前的测试配置](guide/testing#feature-module-import)将真实的`HeroService`替换为`FakeHeroService`，拦截了服务起请求，伪造了它们的响应。

What if you aren't so lucky. What if faking the `HeroService` is hard? What if `HeroDetailService` makes its own server requests? 如果我们没有这么幸运怎么办？如果伪造`HeroService`很难怎么办？如果`HeroDetailService`自己发出服务器请求怎么办？ The `TestBed.overrideComponent` method can replace the component's `providers` with easy-to-manage _test doubles_ as seen in the following setup variation: `TestBed.overrideComponent`方法可以将组件的`providers`替换为容易管理的**测试替身**，参见下面的设置变化： Notice that `TestBed.configureTestingModule` no longer provides a (fake) `HeroService` because it's [not needed](guide/testing#spy-stub). 注意，`TestBed.configureTestingModule`不再提供（伪造）`HeroService`，因为已经[没有必要了](guide/testing#stub-hero-detail-service)。 {@a override-component-method} ### The _overrideComponent_ method ### **overrideComponent**方法 Focus on the `overrideComponent` method. 注意这个`overrideComponent`方法。 It takes two arguments: the component type to override (`HeroDetailComponent`) and an override metadata object. The [overide metadata object](guide/testing#metadata-override-object) is a generic defined as follows: 它接受两个参数：要重载的组件类型(`HeroDetailComponent`)和用于重载的元数据对象。 [重载元数据对象](guide/testing#metadata-override-object)是泛型类，就像这样： type MetadataOverride = { add?: T; remove?: T; set?: T; }; A metadata override object can either add-and-remove elements in metadata properties or completely reset those properties. This example resets the component's `providers` metadata. 元数据重载对象可以添加和删除元数据属性的项目，也可以彻底重设这些属性。这个例子重新设置了组件的`providers`元数据。 The type parameter, `T`, is the kind of metadata you'd pass to the `@Component` decorator: 这个类型参数，`T`，是你会传递给`@Component`装饰器的元数据的类型。 selector?: string; template?: string; templateUrl?: string; providers?: any[]; ... {@a spy-stub} ### Provide a _spy stub_ (_HeroDetailServiceSpy_) ### 提供一个*刺探桩（Spy stub）*（`HeroDetailServiceSpy`） This example completely replaces the component's `providers` array with a new array containing a `HeroDetailServiceSpy`. 这个例子把组件的`providers`数组完全替换成了一个包含`HeroDetailServiceSpy`的新数组。 The `HeroDetailServiceSpy` is a stubbed version of the real `HeroDetailService` that fakes all necessary features of that service. It neither injects nor delegates to the lower level `HeroService` so there's no need to provide a test double for that. `HeroDetailServiceSpy`是实际`HeroDetailService`服务的桩版本，它伪造了该服务的所有必要特性。但它既不需要注入也不会委托给低层的`HeroService`服务，因此我们不用为`HeroService`提供测试替身。 The related `HeroDetailComponent` tests will assert that methods of the `HeroDetailService` were called by spying on the service methods. Accordingly, the stub implements its methods as spies: 通过对该服务的方法进行刺探，`HeroDetailComponent`的关联测试将会对`HeroDetailService`是否被调用过进行断言。因此，这个桩类会把它的方法实现为刺探方法： {@a override-tests} ### The override tests ### 重载的测试程序 Now the tests can control the component's hero directly by manipulating the spy-stub's `testHero` and confirm that service methods were called. 现在，测试程序可以通过操控stub的`testHero`，直接控制组件的英雄，并确保服务的方法被调用过。 {@a more-overrides} ### More overrides ### 更多重载 The `TestBed.overrideComponent` method can be called multiple times for the same or different components. The `TestBed` offers similar `overrideDirective`, `overrideModule`, and `overridePipe` methods for digging into and replacing parts of these other classes. `TestBed.overrideComponent`方法可以在相同或不同的组件中被反复调用。 `TestBed`还提供了类似的`overrideDirective`、`overrideModule`和`overridePipe`方法，用来深入并重载这些其它类的部件。 Explore the options and combinations on your own. 自己探索这些选项和组合。 Back to top 回到顶部

{@a router-outlet-component} ## Test a _RouterOutlet_ component ## 测试带有_RouterOutlet_的组件 The `AppComponent` displays routed components in a ``. It also displays a navigation bar with anchors and their `RouterLink` directives. `AppComponent`在``中显示导航组件。它还显示了导航条，包含了链接和它们的`RouterLink`指令。 {@a app-component-html} The component class does nothing. 组件的类没有做任何事。 Unit tests can confirm that the anchors are wired properly without engaging the router. See why this is worth doing [below](guide/testing#why-stubbed-routerlink-tests). 在不涉及路由的情况下，单元测试可以确认链接的设置是否正确。参见[下面的内容](guide/testing#why-stubbed-routerlink-tests)，了解为什么值得这么做。 {@a stub-component} ### Stubbing unneeded components ### stub伪造不需要的组件 The test setup should look familiar. 该测试配置应该看起来很眼熟： The `AppComponent` is the declared test subject. `AppComponent`是被声明的测试对象。 The setup extends the default testing module with one real component (`BannerComponent`) and several stubs. 使用一个真实的组件（`BannerComponent`）和几个stub，该配置扩展了默认测试模块。 * `BannerComponent` is simple and harmless to use as is. 原样使用`BannerComponent`非常简单而且无害。 * The real `WelcomeComponent` has an injected service. `WelcomeStubComponent` is a placeholder with no service to worry about. 真实的`WelcomeComponent`有被注入的服务。`WelcomeStubComponent`是无服务的替代品。 * The real `RouterOutlet` is complex and errors easily. The `RouterOutletStubComponent` (in `testing/router-stubs.ts`) is safely inert. 真实的`RouterOutlet`很复杂而且容易出错。 `testing/router-stubs.ts`里的`RouterOutletStubComponent`是安全的替代品。 The component stubs are essential. Without them, the Angular compiler doesn't recognize the `` and `` tags and throws an error. 组件stub替代品很关键。没有它们，Angular编译器无法识别``标签，抛出错误。 {@a router-link-stub} ### Stubbing the _RouterLink_ ### Stub伪造_RouterLink_ The `RouterLinkStubDirective` contributes substantively to the test: `RouterLinkStubDirective`为测试作出了重要的贡献： The `host` metadata property wires the click event of the host element (the ``) to the directive's `onClick` method. The URL bound to the `[routerLink]` attribute flows to the directive's `linkParams` property. Clicking the anchor should trigger the `onClick` method which sets the telltale `navigatedTo` property. Tests can inspect that property to confirm the expected _click-to-navigation_ behavior. `host`元数据属性将宿主元素(``)的click事件与指令的`onClick`方法关联起来。绑定到`[routerLink]`的URL属性被传递到指令的`linkParams`属性。点击这个链接应该能触发`onClick`方法，从而设置`navigatedTo`属性。测试程序可以查看这个属性，来确认期望的**点击导航**行为。 {@a by-directive} {@a inject-directive} ### _By.directive_ and injected directives ### _By.directive_和注入的指令 A little more setup triggers the initial data binding and gets references to the navigation links: 再一步配置触发了数据绑定的初始化，获取导航链接的引用： Two points of special interest: 特别值得注意的两点： 1. You can locate elements _by directive_, using `By.directive`, not just by css selectors. 你还可以按指令定位元素，使用`By.directive`，而不仅仅是通过CSS选择器。 1. You can use the component's dependency injector to get an attached directive because Angular always adds attached directives to the component's injector. 你可以使用组件的依赖注入器来获取附加的指令，因为Angular总是将附加组件添加到组件的注入器中。 {@a app-component-tests} Here are some tests that leverage this setup: 下面是一些使用这个配置的测试程序：

The "click" test _in this example_ is worthless. 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 guide. It demonstrates how to find a `RouterLink` element, click it, and inspect a result, without engaging the full router machinery. This is a skill you may need to test a more sophisticated component, one that changes the display, re-calculates parameters, or re-arranges navigation options when the user clicks the link. 在本章中，它有存在的必要。它演示了如何在不涉及完整路由器机制的情况下，如何找到`RouterLink`元素、点击它并检查结果。要测试更复杂的组件，你可能需要具备这样的能力，能改变视图和重新计算参数，或者当用户点击链接时，有能力重新安排导航选项。

{@a why-stubbed-routerlink-tests} ### What good are these tests? ### 这些测试有什么好处？ Stubbed `RouterLink` tests can confirm that a component with links and an outlet is setup properly, that the component has the links it should have, and that they are all pointing in the expected direction. These tests do not concern whether the app will succeed in navigating to the target component when the user clicks a link. stub伪造的`RouterLink`测试可以确认带有链接和outlet的组件的设置的正确性，确认组件有应该有的链接，确认它们都指向了正确的方向。这些测试程序不关心用户点击链接时，应用是否会成功的导航到目标组件。 Stubbing the RouterLink and RouterOutlet is the best option for such limited testing goals. Relying on the real router would make them brittle. They could fail for reasons unrelated to the component. 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 guide update will explain how to write such tests with the `RouterTestingModule`. 未来本章的更新将介绍如何使用`RouterTestingModule`来编写这样的测试程序。

{@a shallow-component-test} ## "Shallow component tests" with *NO\_ERRORS\_SCHEMA* ## 使用*NO\_ERRORS\_SCHEMA*来“浅化”组件测试程序 The [previous setup](guide/testing#stub-component) declared the `BannerComponent` and stubbed two other components for _no reason other than to avoid a compiler error_. [以前的配置](guide/testing#stub-component)声明了`BannerComponent`，并stub伪造了两个其它组件，**仅仅是为了避免编译错误，不是为别的原因**。 Without them, the Angular compiler doesn't recognize the ``, `` and `` tags in the [_app.component.html_](guide/testing#app-component-html) template and throws an error. 没有它们，Angular编译器无法识别[_app.component.html_](guide/testing#app-component-html)模板里的``、``和``标签，并抛出错误。 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伪造的配置来说，**浅**测试程序的简单性。

The _only_ declarations are the _component-under-test_ (`AppComponent`) and the `RouterLinkStubDirective` that contributes actively to the tests. The [tests in this example](guide/testing#app-component-tests) are unchanged. 这里**唯一**声明的是**被测试的组件**(`AppComponent`)和测试需要的`RouterLinkStubDirective`。没有改变任何[原测试程序](guide/testing#app-component-tests)。

_Shallow component tests_ with `NO_ERRORS_SCHEMA` greatly simplify unit testing of complex templates. However, the compiler no longer alerts you to mistakes such as misspelled or misused components and directives. 使用`NO_ERRORS_SCHEMA`的**浅组件测试程序**很大程度上简化了拥有复杂模板组件的单元测试。但是，编译器将不再提醒你一些错误，比如模板中拼写错误或者误用的组件和指令。

{@a attribute-directive} ## Test an attribute directive ## 测试属性指令 An _attribute directive_ modifies the behavior of an element, component or another directive. Its name reflects the way the directive is applied: as an attribute on a host element. **属性指令**修改元素、组件和其它指令的行为。正如它们的名字所示，它们是作为宿主元素的属性来被使用的。 The sample application's `HighlightDirective` sets the background color of an element based on either a data bound color or a default color (lightgray). It also sets a custom property of the element (`customProperty`) to `true` for no reason other than to show that it can. 本例子应用的`HighlightDirective`使用数据绑定的颜色或者默认颜色来设置元素的背景色。它同时设置元素的`customProperty`属性为`true`，这里仅仅是为了显示它能这么做而已，并无其它原因。 It's used throughout the application, perhaps most simply in the `AboutComponent`: 它的使用贯穿整个应用，也许最简单的使用在`AboutComponent`里： Testing the specific use of the `HighlightDirective` within the `AboutComponent` requires only the techniques explored above (in particular the ["Shallow test"](guide/testing#shallow-component-test) approach). 使用`AboutComponent`来测试这个`HightlightDirective`的使用，只需要上面解释过的知识就够了，（尤其是["浅测试程序"](guide/testing#shallow-component-test)方法)。 However, testing a single use case is unlikely to explore the full range of a directive's capabilities. Finding and testing all components that use the directive is tedious, brittle, and almost as unlikely to afford full coverage. 但是，测试单一的用例一般无法探索该指令的全部能力。查找和测试所有使用该指令的组件非常繁琐和脆弱，并且通常无法覆盖所有组件。 [Isolated unit tests](guide/testing#isolated-unit-tests) might be helpful, but attribute directives like this one tend to manipulate the DOM. Isolated unit tests don't touch the DOMand, therefore , do not inspire confidence in the directive's efficacy. [孤立单元测试](guide/testing#isolated-unit-tests)可能有用。但是像这样的属性指令一般都操纵DOM。孤立单元测试不能控制DOM，所以不推荐用它测试指令的功能。 A better solution is to create an artificial test component that demonstrates all ways to apply the directive. 更好的方法是创建一个展示所有使用该组件的方法的人工测试组件。

The `` case binds the `HighlightDirective` to the name of a color value in the input box. The initial value is the word "cyan" which should be the background color of the input box. ``用例将`HighlightDirective`绑定到输入框里输入的颜色名字。初始只是单词“cyan”，所以输入框的背景色应该是cyan。

Here are some tests of this component: 下面是一些该组件的测试程序： A few techniques are noteworthy: 一些技巧值得注意： * The `By.directive` predicate is a great way to get the elements that have this directive _when their element types are unknown_. 当**已知元素类型**时，`By.directive`是一种获取拥有这个指令的元素的好方法。 * The `:not` pseudo-class in `By.css('h2:not([highlight])')` helps find `

` elements that _do not_ have the directive. `By.css('*:not([highlight])')` finds _any_ element that does not have the directive. `By.css('h2:not([highlight])')`里的`:not`伪类（pseudo-class）帮助查找不带该指令的`

`元素。`By.css(':not([highlight])')`查找所有不带该指令的元素。 `DebugElement.styles` affords access to element styles even in the absence of a real browser, thanks to the `DebugElement` abstraction. But feel free to exploit the `nativeElement` when that seems easier or more clear than the abstraction. `DebugElement.styles`让我们不借助真实的浏览器也可以访问元素的样式，感谢`DebugElement`提供的这层抽象！但是如果直接使用`nativeElement`会比这层抽象更简单、更清晰，也可以放心大胆的使用它。 * Angular adds a directive to the injector of the element to which it is applied. The test for the default color uses the injector of the second `

` to get its `HighlightDirective` instance and its `defaultColor`. Angular将指令添加到它的元素的注入器中。默认颜色的测试程序使用第二个`

`的注入器来获取它的`HighlightDirective`实例以及它的`defaultColor`。 * `DebugElement.properties` affords access to the artificial custom property that is set by the directive. `DebugElement.properties`让我们可以访问由指令设置的自定义属性。 Back to top 回到顶部
{@a isolated-unit-tests} ## Isolated Unit Tests ## 孤立的单元测试 Testing applications with the help of the Angular testing utilities is the main focus of this guide. 使用Angular测试工具测试应用程序是本章的重点。 However, it's often more productive to explore the inner logic of application classes with _isolated_ unit tests that don't depend upon Angular. Such tests are often smaller and easier to read, write, and maintain. 但是，使用孤立单元测试来探索应用类的内在逻辑往往更加有效率，它不依赖Angular。这种测试程序通常比较小、更易阅读、编写和维护。 They don't carry extra baggage: 它们不用背负额外的包袱： * Import from the Angular test libraries. 从Angular测试库导入 * Configure a module. 配置模块 * Prepare dependency injection `providers`. 准备依赖注入`providers` * Call `inject` or `async` or `fakeAsync`. 调用`inject`，或者`async`，或者`fakeAsync` They follow patterns familiar to test developers everywhere: 它们会遵循测试时众所周知的模式： * Exhibit standard, Angular-agnostic testing techniques. 使用标准的、与Angular无关的测试技巧 * Create instances directly with `new`. 直接使用`new`创建实例 * Substitute test doubles (stubs, spys, and mocks) for the real dependencies. 用测试替身（stub，spy和mock）替代真正的依赖

Write both kinds of tests

同时采用这两种测试程序
Good developers write both kinds of tests for the same application part, often in the same spec file. Write simple _isolated_ unit tests to validate the part in isolation. Write _Angular_ tests to validate the part as it interacts with Angular, updates the DOM, and collaborates with the rest of the application. 优秀的开发者同时编写这两种测试程序来测试相同的应用部件，往往在同一个spec文件。编写简单的孤立单元测试程序来验证孤立的部分。编写Angular测试程序来验证与Angular互动、更新DOM、以及与应用其它部分互动的部分。
{@a isolated-service-tests} ### Services ### 服务 Services are good candidates for isolated unit testing. Here are some synchronous and asynchronous unit tests of the `FancyService` written without assistance from Angular testing utilities. 服务是应用孤立测试的好例子。下面是未使用Angular测试工具的一些`FancyService`的同步和异步单元测试： A rough line count suggests that these isolated unit tests are about 25% smaller than equivalent Angular tests. That's telling but not decisive. The benefit comes from reduced setup and code complexity. 粗略行数表明，这些孤立单元测试比同等的Angular测试小25%。这表明了它的好处，但是不是最关键的。主要的好处来自于缩减的配置和代码的复杂性。 Compare these equivalent tests of `FancyService.getTimeoutValue`. 比较下面两个同等的`FancyService.getTimeoutValue`测试程序： They have about the same line-count, but the Angular-dependent version has more moving parts including a couple of utility functions (`async` and `inject`). Both approaches work and it's not much of an issue if you're using the Angular testing utilities nearby for other reasons. On the other hand, why burden simple service tests with added complexity? 它们有类似的行数。但是，依赖Angular的版本有更多活动的部分，包括一些工具函数（`async`和`inject`)。两种方法都可行，而且如果你为了某些原因使用Angular测试工具，也并没有什么问题。反过来，为什么要为简单的服务测试程序添加复杂度呢？ Pick the approach that suits you. 选择你喜欢的方法。 {@a services-with-dependencies} ### Services with dependencies ### 带依赖的服务 Services often depend on other services that Angular injects into the constructor. You can test these services _without_ the `TestBed`. In many cases, it's easier to create and _inject_ dependencies by hand. 服务通常依赖其它服务，Angular通过构造函数注入它们。你可以不使用TestBed测试这些服务。在许多情况下，创建和手动注入依赖来的更加容易。 The `DependentService` is a simple example: `DependentService`是一个简单的例子： It delegates its only method, `getValue`, to the injected `FancyService`. 它将唯一的方法，`getValue`，委托给了注入的`FancyService`。 Here are several ways to test it. 这里是几种测试它的方法。 The first test creates a `FancyService` with `new` and passes it to the `DependentService` constructor. 第一个测试程序使用`new`创建`FancyService`实例，并将它传递给`DependentService`构造函数。 However, it's rarely that simple. The injected service can be difficult to create or control. You can mock the dependency, use a dummy value, or stub the pertinent service method with a substitute method that 's easy to control. 很少有这么简单的，注入的服务有可能很难创建和控制。你可以mock依赖，或者使用假值，或者用易于控制的替代品stub伪造相关服务。 These _isolated_ unit testing techniques are great for exploring the inner logic of a service or its simple integration with a component class. Use the Angular testing utilities when writing tests that validate how a service interacts with components _within the Angular runtime environment_. 这些孤立单元测试技巧是一个很好的方法，用来探索服务的内在逻辑，以及它与组件类简单的集成。当在运行时间环境下，使用Angular测试工具来验证一个服务是如何与组件互动的。 {@a isolated-pipe-tests} ### Pipes ### 管道 Pipes are easy to test without the Angular testing utilities. 管道很容易测试，无需Angular测试工具。 A pipe class has one method, `transform`, that manipulates the input value into a transformed output value. The `transform` implementation rarely interacts with the DOM. Most pipes have no dependence on Angular other than the `@Pipe` metadata and an interface. 管道类有一个方法，`transform`，用来转换输入值到输出值。 `transform`的实现很少与DOM交互。除了`@Pipe`元数据和一个接口外，大部分管道不依赖Angular。 Consider a `TitleCasePipe` that capitalizes the first letter of each word. Here's a naive implementation with a regular expression. 假设`TitleCasePipe`将每个单词的第一个字母变成大写。下面是使用正则表达式实现的简单代码： Anything that uses a regular expression is worth testing thoroughly. Use simple Jasmine to explore the expected cases and the edge cases. 任何使用正则表达式的类都值得彻底的进行测试。使用Jasmine来探索预期的用例和极端的用例。 {@a write-tests} ### Write Angular tests too ### 同时也编写Angular测试 These are tests of the pipe _in isolation_. They can't tell if the `TitleCasePipe` is working properly as applied in the application components. 有些管道的测试程序是孤立的。它们不能验证`TitleCasePipe`是否在应用到组件上时是否工作正常。 Consider adding component tests such as this one: 考虑像这样添加组件测试程序： {@a isolated-component-tests} ### Components ### 组件 Component tests typically examine how a component class interacts with its own template or with collaborating components. The Angular testing utilities are specifically designed to facilitate such tests. 组件测试通常检查该组件类是如何与自己的模板或者其它合作组件交互的。 Angular测试工具是专门为这种测试设计的。 Consider this `ButtonComp` component. 考虑这个`ButtonComp`组件。 The following Angular test demonstrates that clicking a button in the template leads to an update of the on-screen message. 下面的Angular测试演示点击模板里的按钮后，引起了屏幕上的消息的更新。 The assertions verify that the data values flow from one HTML control (the `

Function 函数	Description 描述
`async`	Runs the body of a test (`it`) or setup (`beforeEach`) function within a special _async test zone_. See [discussion above](guide/testing#async). 在特殊的async测试区域运行测试程序（`it`)或者设置（`beforeEach`）的主体。参见[上面的讨论](guide/testing#async).
`fakeAsync`	Runs the body of a test (`it`) within a special _fakeAsync test zone_, enabling a linear control flow coding style. See [discussion above](guide/testing#fake-async). 在特殊的fakeAsync测试区域运行测试程序（`it`）的主体，造就控制流更加线性的代码风格。参见[上面的讨论](guide/testing#fake-async).
`tick`	Simulates the passage of time and the completion of pending asynchronous activities by flushing both _timer_ and _micro-task_ queues within the _fakeAsync test zone_. 在fakeAsync测试区域内触发计时器和微任务队列，以模拟时间的推移和未完成异步任务的完成。 The curious, dedicated reader might enjoy this lengthy blog post, ["_Tasks, microtasks, queues and schedules_"](https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/). 好奇和执着的读者可能会喜欢这篇长博客： "_Tasks, microtasks, queues and schedules_". Accepts an optional argument that moves the virtual clock forward by the specified number of milliseconds, clearing asynchronous activities scheduled within that timeframe. See [discussion above](guide/testing#tick). 接受一个可选参数，往前推移虚拟时间提供数字的毫秒数，清除在这段时间内的异步行为。参见[上面的讨论](guide/testing#tick)
`inject`	Injects one or more services from the current `TestBed` injector into a test function. See [above](guide/testing#inject). 从当前`TestBed`注入器注入一个或多个服务到测试函数。参见[上面](guide/testing#inject)。
`discardPeriodicTasks`	When a `fakeAsync` test ends with pending timer event _tasks_ (queued `setTimeOut` and `setInterval` callbacks), the test fails with a clear error message. 当`fakeAsync`测试程序以正在运行的计时器事件任务（排队中的`setTimeOut`和`setInterval`的回调）结束时，测试会失败，并显示一条明确的错误信息。 In general, a test should end with no queued tasks. When pending timer tasks are expected, call `discardPeriodicTasks` to flush the _task_ queue and avoid the error. 一般来讲，测试程序应该以无排队任务结束。当待执行计时器任务存在时，调用`discardPeriodicTasks`来触发任务队列，防止该错误发生。
`flushMicrotasks`	When a `fakeAsync` test ends with pending _micro-tasks_ such as unresolved promises, the test fails with a clear error message. 当`fakeAsync`测试程序以待执行微任务（比如未解析的承诺）结束时，测试会失败并显示明确的错误信息。 In general, a test should wait for micro-tasks to finish. When pending microtasks are expected, call `flushMicrotasks` to flush the _micro-task_ queue and avoid the error. 一般来说，测试应该等待微任务结束。当待执行微任务存在时，调用`flushMicrotasks`来触发微任务队列，防止该错误发生。
`ComponentFixtureAutoDetect`	A provider token for a service that turns on [automatic change detection](guide/testing#automatic-change-detection). 一个提供商令牌，用来设置auto-changeDetect的值，它默认值为`false`。参见[自动变更检测](guide/testing#automatic-change-detection)
`getTestBed`	Gets the current instance of the `TestBed`. Usually unnecessary because the static class methods of the `TestBed` class are typically sufficient. The `TestBed` instance exposes a few rarely used members that are not available as static methods. 获取当前`TestBed`实例。通常用不上，因为`TestBed`的静态类方法已经够用。 `TestBed`实例有一些很少需要用到的方法，它们没有对应的静态方法。

Methods 方法	Description 描述
`configureTestingModule`	The testing shims (`karma-test-shim`, `browser-test-shim`) establish the [initial test environment](guide/testing) and a default testing module. The default testing module is configured with basic declaratives and some Angular service substitutes that every tester needs. 测试垫片（`karma-test-shim`, `browser-test-shim`）创建了[初始测试环境](guide/testing)和默认测试模块。默认测试模块是使用基本声明和一些Angular服务替代品，它们是所有测试程序都需要的。 Call `configureTestingModule` to refine the testing module configuration for a particular set of tests by adding and removing imports, declarations (of components, directives, and pipes), and providers. 调用`configureTestingModule`来为一套特定的测试定义测试模块配置，添加和删除导入、（组件、指令和管道的）声明和服务提供商。
`compileComponents`	Compile the testing module asynchronously after you've finished configuring it. You must call this method if _any_ of the testing module components have a `templateUrl` or `styleUrls` because fetching component template and style files is necessarily asynchronous. See [above](guide/testing#compile-components). 在你完成配置以后异步编译测试模块。如果任何测试组件有`templateUrl`或`styleUrls`，那么你必须调用这个方法。因为获取组件模块和样式文件必须是异步的。参见[上面的描述](guide/testing#compile-components)。 After calling `compileComponents`, the `TestBed` configuration is frozen for the duration of the current spec. 调用完`compileComponents`之后，`TestBed`的配置就会在当前测试期间被冻结。
`createComponent`	Create an instance of a component of type `T` based on the current `TestBed` configuration. After calling `compileComponent`, the `TestBed` configuration is frozen for the duration of the current spec. 基于当前`TestBed`的配置创建一个类型为T的组件实例。一旦调用，`TestBed`的配置就会在当前测试期间被冻结。
`overrideModule`	Replace metadata for the given `NgModule`. Recall that modules can import other modules. The `overrideModule` method can reach deeply into the current testing module to modify one of these inner modules. 替换指定的`NgModule`的元数据。回想一下，模块可以导入其他模块。 `overrideModule`方法可以深入到当前测试模块深处，修改其中一个内部模块。
`overrideComponent`	Replace metadata for the given component class, which could be nested deeply within an inner module. 替换指定组件类的元数据，该组件类可能嵌套在一个很深的内部模块中。
`overrideDirective`	Replace metadata for the given directive class, which could be nested deeply within an inner module. 替换指定指令类的元数据，该指令可能嵌套在一个很深的内部模块中。
`overridePipe`	Replace metadata for the given pipe class, which could be nested deeply within an inner module. 替换指定管道类的元数据，该管道可能嵌套在一个很深的内部模块中。
{@a testbed-get} `get`	Retrieve a service from the current `TestBed` injector. 从当前`TestBed`注入器获取一个服务。 The `inject` function is often adequate for this purpose. But `inject` throws an error if it can't provide the service. What if the service is optional? `inject`函数通常很适合这个任务。但是如果`inject`不能提供服务，它会抛出错误。如果服务是可选的呢？ The `TestBed.get` method takes an optional second parameter, the object to return if Angular can't find the provider (`null` in this example): `TestBed.get`方法接受一个可选的第二参数，它是在Angular找不到所需提供商时返回的对象。（在本例中为`null`）： After calling `get`, the `TestBed` configuration is frozen for the duration of the current spec. 一旦调用，`TestBed`的配置就会在当前测试期间被冻结。
{@a testbed-initTestEnvironment} `initTestEnvironment`	Initialize the testing environment for the entire test run. 为整套测试的运行初始化测试环境。 The testing shims (`karma-test-shim`, `browser-test-shim`) call it for you so there is rarely a reason for you to call it yourself. 测试垫片(`karma-test-shim`, `browser-test-shim`)会为你调用它，所以你很少需要自己调用它。 You may call this method _exactly once_. If you must change this default in the middle of your test run, call `resetTestEnvironment` first. 这个方法只能被调用一次。如果确实需要在测试程序运行期间变换这个默认设置，那么先调用`resetTestEnvironment`。 Specify the Angular compiler factory, a `PlatformRef`, and a default Angular testing module. Alternatives for non-browser platforms are available in the general form `@angular/platform-/testing/`. 指定Angular编译器工厂，`PlatformRef`，和默认Angular测试模块。以`@angular/platform-/testing/`的形式提供非浏览器平台的替代品。
`resetTestEnvironment`	Reset the initial test environment, including the default testing module. 重设初始测试环境，包括默认测试模块在内。

Properties 属性	Description 描述
`componentInstance`	The instance of the component class created by `TestBed.createComponent`. 被`TestBed.createComponent`创建的组件类实例。
`debugElement`	The `DebugElement` associated with the root element of the component. 与组件根元素关联的`DebugElement`。 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](guide/testing#debug-element-details). `debugElement`在测试和调试期间，提供对组件及其DOM元素的访问。它是测试者至关重要的属性。它最有用的成员在[下面](guide/testing#debug-element-details)有所介绍。
`nativeElement`	The native DOM element at the root of the component. 组件的原生根DOM元素。
`changeDetectorRef`	The `ChangeDetectorRef` for the component. 组件的`ChangeDetectorRef`。 The `ChangeDetectorRef` is most valuable when testing a component that has the `ChangeDetectionStrategy.OnPush` method or the component's change detection is under your programmatic control. 在测试一个拥有`ChangeDetectionStrategy.OnPush`的组件，或者在组件的变化测试在你的程序控制下时，`ChangeDetectorRef`是最重要的。

Methods 方法	Description 描述
`detectChanges`	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`. 调用它来初始化组件（它调用`ngOnInit`）。或者在你的测试代码改变了组件的数据绑定属性值后调用它。 Angular不能检测到你已经改变了`personComponent.name`属性，也不会更新`name`的绑定，直到你调用了`detectChanges`。 Runs `checkNoChanges`afterwards to confirm that there are no circular updates unless called as `detectChanges(false)`; 之后，运行`checkNoChanges`，来确认没有循环更新，除非它被这样调用：`detectChanges(false)`。
`autoDetectChanges`	Set this to `true` when you want the fixture to detect changes automatically. 设置fixture是否应该自动试图检测变化。 When autodetect is `true`, the test fixture calls `detectChanges` immediately after creating the component. Then it listens for pertinent zone events and calls `detectChanges` accordingly. When your test code modifies component property values directly, you probably still have to call `fixture.detectChanges` to trigger data binding updates. 当自动检测打开时，测试fixture监听zone事件，并调用`detectChanges`。当你的测试代码直接修改了组件属性值时，你还是要调用`fixture.detectChanges`来触发数据绑定更新。 The default is `false`. Testers who prefer fine control over test behavior tend to keep it `false`. 默认值是`false`，喜欢对测试行为进行精细控制的测试者一般保持它为`false`。
`checkNoChanges`	Do a change detection run to make sure there are no pending changes. Throws an exceptions if there are. 运行一次变更检测来确认没有待处理的变化。如果有未处理的变化，它将抛出一个错误。
`isStable`	If the fixture is currently _stable_, returns `true`. If there are async tasks that have not completed, returns `false`. 如果fixture当前是稳定的，则返回`true`。如果有异步任务没有完成，则返回`false`。
`whenStable`	Returns a promise that resolves when the fixture is stable. 返回一个承诺，在fixture稳定时解析。 To resume testing after completion of asynchronous activity or asynchronous change detection, hook that promise. See [above](guide/testing#when-stable). 钩住这个承诺，以在异步行为或者异步变更检测之后继续测试。参见[上面](guide/testing#when-stable)。
`destroy`	Trigger component destruction. 触发组件的销毁。

Member 成员	Description 描述
`nativeElement`	The corresponding DOM element in the browser (null for WebWorkers). 与浏览器中DOM元素对应（WebWorkers时，值为null）。
`query`	Calling `query(predicate: Predicate)` returns the first `DebugElement` that matches the [predicate](guide/testing#query-predicate) at any depth in the subtree. 调用`query(predicate: Predicate)`返回子树所有层中第一个匹配[predicate](guide/testing#query-predicate)的`DebugElement`。
`queryAll`	Calling `queryAll(predicate: Predicate)` returns all `DebugElements` that matches the [predicate](guide/testing#query-predicate) at any depth in subtree. 调用`query(predicate: Predicate)`返回子树所有层中所有匹配[predicate](guide/testing#query-predicate)`DebugElement`。
`injector`	The host dependency injector. For example, the root element's component instance injector. 宿主依赖注入器。比如，根元素的组件实例注入器。
`componentInstance`	The element's own component instance, if it has one. 元素自己的组件实例（如果有）。
`context`	An object that provides parent context for this element. Often an ancestor component instance that governs this element. 为元素提供父级上下文的对象。通常是控制该元素的祖级组件实例。 When an element is repeated within `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"`. 当一个元素被`ngFor`重复，它的上下文为`NgForRow`，它的`$implicit`属性值是该行的实例值。比如，`ngFor="let hero of heroes"`里的`hero`。
`children`	The immediate `DebugElement` children. Walk the tree by descending through `children`. `DebugElement`的直接子级。通过`children`来降序探索元素树。 `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. `DebugElement`还有`childNodes`，即`DebugNode`对象列表。 `DebugElement`从`DebugNode`对象衍生，而且通常节点（node）比元素多。测试者通常忽略赤裸节点。
`parent`	The `DebugElement` parent. Null if this is the root element. `DebugElement`的父级。如果`DebugElement`是根元素，`parent`为null。
`name`	The element tag name, if it is an element. 元素的标签名字，如果它是一个元素的话。
`triggerEventHandler`	Triggers the event by its name if there is a corresponding listener in the element's `listeners` collection. The second parameter is the _event object_ expected by the handler. See [above](guide/testing#trigger-event-handler). 如果在元素的`listeners`列表中有一个对应的`listener`，则以事件名字触发。第二个参数是事件对象，一般为事件处理器。参见[上面](guide/testing#trigger-event-handler)。 If the event lacks a listener or there's some other problem, consider calling `nativeElement.dispatchEvent(eventObject)`. 如果事件缺乏监听器，或者有其它问题，考虑调用`nativeElement.dispatchEvent(eventObject)`。
`listeners`	The callbacks attached to the component's `@Output` properties and/or the element's event properties. 元素的`@Output`属性以及/或者元素的事件属性所附带的回调函数。
`providerTokens`	This component's injector lookup tokens. Includes the component itself plus the tokens that the component lists in its `providers` metadata. 组件注入器的查询令牌。包括组件自己的令牌和组件的`providers`元数据中列出来的令牌。
`source`	Where to find this element in the source component template. source是在源组件模板中查询这个元素的处所。
`references`	Dictionary of objects associated with template local variables (e.g. `#foo`), keyed by the local variable name. 与模板本地变量（比如`#foo`）关联的词典对象，关键字与本地变量名字配对。

` tag. 大多数开发人员首先要测试的就是Angular组件。 `src/app/banner-inline.component.ts`中的`BannerComponent`是这个应用中最简单的组件，也是一个好的起点。它所表示的是屏幕顶部`

` tags. Use the fixture's `DebugElement` to `query` for the `

` element by CSS selector. `title`属性被插值到DOM的`

`标签中。用CSS选择器从fixture的`DebugElement`中`query``

` elements that _do not_ have the directive. `By.css('*:not([highlight])')` finds _any_ element that does not have the directive. `By.css('h2:not([highlight])')`里的`:not`伪类（pseudo-class）帮助查找不带该指令的`

` to get its `HighlightDirective` instance and its `defaultColor`. Angular将指令添加到它的元素的注入器中。默认颜色的测试程序使用第二个`

File 文件	Description 描述
`karma.conf.js`	The karma configuration file that specifies which plug-ins to use, which application and test files to load, which browser(s) to use, and how to report test results. 这个karma配置文件指定了要使用那些插件、要加载那些应用文件和测试文件、要使用哪些浏览器以及如何报告测试结果。 It loads three other setup files: 它加载了下列设置文件： * `systemjs.config.js` * `systemjs.config.extras.js` * `karma-test-shim.js`
`karma-test-shim.js`	This shim prepares karma specifically for the Angular test environment and launches karma itself. It loads the `systemjs.config.js` file as part of that process. 这个垫片（shim）文件为karma准备Angular特有的测试环境，并启动karma自身。这期间，它还加载`systemjs.config.js`文件。
`systemjs.config.js`	[SystemJS](https://github.com/systemjs/systemjs/blob/master/README.md) loads the application and test files. This script tells SystemJS where to find those files and how to load them. It's the same version of `systemjs.config.js` you installed during [setup](guide/testing#setup). [SystemJS](https://github.com/systemjs/systemjs/blob/master/README.md)加载应用文件和测试文件。这个脚本告诉SystemJS到哪里去找那些文件，以及如何加载它们。它和你在[环境设置](guide/testing#setup)期间安装的那个`systemjs.config.js`是同一个版本。
`systemjs.config.extras.js`	An optional file that supplements the SystemJS configuration in `systemjs.config.js` with configuration for the specific needs of the application itself. 一个可选的文件，它会为`systemjs.config.js`中提供SystemJS的配置加上应用自身需要的特殊配置。 A stock `systemjs.config.js` can't anticipate those needs. You fill the gaps here. 常规的`systemjs.config.js`文件无法满足那些需求，我们需要自己填充它。 The sample version for this guide adds the model barrel to the SystemJs `packages` configuration. 本章的例子中把*模型桶（barrel）添加到了SystemJS的`packages`配置中。

` tag. 大多数开发人员首先要测试的就是Angular组件。 `src/app/banner-inline.component.ts`中的`BannerComponent`是这个应用中最简单的组件，也是一个好的起点。 它所表示的是屏幕顶部`

` tags. Use the fixture's `DebugElement` to `query` for the `

` element by CSS selector. `title`属性被插值到DOM的`

`标签中。 用CSS选择器从fixture的`DebugElement`中`query``

` elements that _do not_ have the directive. `By.css('*:not([highlight])')` finds _any_ element that does not have the directive. `By.css('h2:not([highlight])')`里的`:not`伪类（pseudo-class）帮助查找**不带**该指令的`

` to get its `HighlightDirective` instance and its `defaultColor`. Angular将指令添加到它的元素的注入器中。默认颜色的测试程序使用第二个`

` tag. 大多数开发人员首先要测试的就是Angular组件。 `src/app/banner-inline.component.ts`中的`BannerComponent`是这个应用中最简单的组件，也是一个好的起点。它所表示的是屏幕顶部`

`标签中。用CSS选择器从fixture的`DebugElement`中`query``

` elements that _do not_ have the directive. `By.css('*:not([highlight])')` finds _any_ element that does not have the directive. `By.css('h2:not([highlight])')`里的`:not`伪类（pseudo-class）帮助查找不带该指令的`