From 6d5cfd568b0a21a87cb457178ecf846830b80628 Mon Sep 17 00:00:00 2001 From: Zhicheng Wang Date: Thu, 15 Mar 2018 08:26:19 +0800 Subject: [PATCH] =?UTF-8?q?fix:=20=E7=BF=BB=E8=AF=91=E4=BA=86=E3=80=8A?= =?UTF-8?q?=E6=B5=8B=E8=AF=95=E3=80=8B=E7=9A=84=E4=B8=80=E9=83=A8=E5=88=86?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- aio/content/guide/testing.md | 861 ++++++++++++++++++++++++++++++++++- 1 file changed, 851 insertions(+), 10 deletions(-) diff --git a/aio/content/guide/testing.md b/aio/content/guide/testing.md index 6e132fd1ae..ad073180fd 100644 --- a/aio/content/guide/testing.md +++ b/aio/content/guide/testing.md @@ -6,13 +6,22 @@ This guide offers tips and techniques for unit and integration testing Angular applications. +该指南提供了对 Angular 应用进行单元测试和集成测试的技巧和提示。 + The guide presents tests of a sample CLI application that is much like the [_Tour of Heroes_ tutorial](tutorial). The sample application and all tests in this guide are available for inspection and experimentation: +该指南中的测试面向的是一个很像[《英雄指南》教程](tutorial)的 CLI 范例应用。 +这个范例应用及其所有测试都可以在下面的链接中进行查看和试用： + * Sample app + 范例应用 + * Tests + 测试 +
## Setup @@ -21,9 +30,14 @@ The sample application and all tests in this guide are available for inspection The Angular CLI downloads and install everything you need to test an Angular application with the [Jasmine test framework](http://jasmine.github.io/2.4/introduction.html). +Angular CLI 会下载并安装试用 [Jasmine 测试框架](http://jasmine.github.io/2.4/introduction.html) 测试 Angular 应用时所需的一切。 + The project you create with the CLI is immediately ready to test. Just run this one CLI command: +你使用 CLI 创建的项目是可以立即用于测试的。 +运行下列 CLI 命令即可： + ng test @@ -33,8 +47,12 @@ Just run this one CLI command: The `ng test` command builds the app in _watch mode_, and launches the [karma test runner](https://karma-runner.github.io/1.0/index.html). +`ng test` 命令在*监视模式*下构建应用，并启动 [karma 测试运行器](https://karma-runner.github.io/1.0/index.html)。 + The console output looks a bit like this: +它的控制台输出一般是这样的： + 10% building modules 1/1 modules 0 active @@ -49,8 +67,12 @@ Chrome ...: Executed 3 of 3 SUCCESS (0.135 secs / 0.205 secs) The last line of the log is the most important. It shows that Karma ran three tests that all passed. +最后一行很重要。它表示 Karma 运行了三个测试，而且这些测试都通过了。 + A chrome browser also opens and displays the test output in the "Jasmine HTML Reporter" like this. +它还会打开 Chrome 浏览器并在“ Jasmine HTML 报告器”中显示测试输出，就像这样： +
Jasmine HTML Reporter in the browser
@@ -58,69 +80,123 @@ A chrome browser also opens and displays the test output in the "Jasmine HTML Re Most people find this browser output easier to read than the console log. You can click on a test row to re-run just that test or click on a description to re-run the tests in the selected test group ("test suite"). +大多数人都会觉得浏览器中的报告比控制台中的日志更容易阅读。 +你可以点击一行测试，来单独重跑这个测试，或者点击一行描述信息来重跑所选测试组（“测试套件”）中的那些测试。 + Meanwhile, the `ng test` command is watching for changes. +同时，`ng test` 命令还会监听这些变化。 + To see this in action, make a small change to `app.component.ts` and save. The tests run again, the browser refreshes, and the new test results appear. +要查看它的实际效果，就对 `app.component.ts` 做一个小修改，并保存它。 +这些测试就会重新运行，浏览器也会刷新，然后新的测试结果就出现了。 + #### Configuration +#### 配置 + The CLI takes care of Jasmine and karma configuration for you. +CLI 会为你生成 Jasmine 和 Karma 的配置文件。 + You can fine-tune many options by editing the `karma.conf.js` file in the project root folder and the `test.ts` file in the `src/` folder. +不过你也可以通过编辑项目根目录下的 `karma.conf.js` 文件以及 `src/` 目录下的 `test.ts` 文件来微调很多选项。 + The `karma.conf.js` file is a partial karma configuration file. The CLI constructs the full runtime configuration in memory,based on application structure specified in the `.angular-cli.json` file, supplemented by `karma.conf.js`. +`karma.conf.js` 文件是 karma 配置文件的一部分。 +CLI 会基于 `.angular-cli.json` 文件中指定的项目结构和 `karma.conf.js` 文件，来在内存中构建出完整的运行时配置。 + Search the web for more details about Jasmine and karma configuration. +要进一步了解 Jasmine 和 Karma 的配置项，请搜索网络。 + #### Other test frameworks +#### 其它测试框架 + You can also unit test an Angular app with other testing libraries and test runners. Each library and runner has its own distinctive installation procedures, configuration, and syntax. +你还可以使用其它的测试库和测试运行器来对 Angular 应用进行单元测试。 +每个库和运行器都有自己特有的安装过程、配置项和语法。 + Search the web to learn more. +要了解更多，请搜索网络。 + #### Test file name and location +#### 测试文件名及其位置 + Look inside the `src/app` folder. +查看 `src/app` 文件夹。 + The CLI generated a test file for the `AppComponent` named `app.component.spec.ts`. +CLI 为 `AppComponent` 生成了一个名叫 `app.component.spec.ts` 的测试文件。 +
The test file extension **must be `.spec.ts`** so that tooling can identify it as a file with tests (AKA, a _spec_ file). +测试文件的扩展名**必须是`.spec.ts`**，这样工具才能识别出它是一个测试文件，也叫规约（spec）文件。 +
The `app.component.ts` and `app.component.spec.ts` files are siblings in the same folder. The root file names (`app.component`) are the same for both files. +`app.component.ts` 和 `app.component.spec.ts` 文件位于同一个文件夹中，而且相邻。 +其根文件名部分（`app.component`）都是一样的。 + Adopt these two conventions in your own projects for _every kind_ of test file. +请在你的项目中对*任意类型*的测试文件都坚持这两条约定。 + ## Service Tests +## 对服务的测试 + Services are often the easiest files to unit test. Here are some synchronous and asynchronous unit tests of the `ValueService` written without assistance from Angular testing utilities. +服务通常是单元测试中最简单的文件类型。 +下面是一些针对 `ValueService` 的同步和异步单元测试， +编写它们时没有借助来自 Angular 测试工具集的任何协助。 + {@a services-with-dependencies} #### Services with dependencies +#### 带有依赖的服务 + Services often depend on other services that Angular injects into the constructor. In many cases, it easy to create and _inject_ these dependencies by hand while calling the service's constructor. +服务通常会依赖于一些 Angular 注入到其构造函数中的其它服务。 +多数情况下，创建并在调用该服务的构造函数时，手工创建并注入这些依赖也是很容易的。 + The `MasterService` is a simple example: +`MasterService` 就是一个简单的例子： + `MasterService` delegates its only method, `getValue`, to the injected `ValueService`. +`MasterService` 把它唯一的方法 `getValue` 委托给了注入进来的 `ValueService`。 + Here are several ways to test it. 这里是几种测试它的方法。 @@ -129,38 +205,63 @@ Here are several ways to test it. The first test creates a `ValueService` with `new` and passes it to the `MasterService` constructor. +第一个测试使用 `new` 创建了 `ValueService`，然后把它传给了 `MasterService` 的构造函数。 + However, injecting the real service rarely works well as most dependent services are difficult to create and control. +不过，对于大多数没这么容易创建和控制的依赖项来说，注入真实的服务很容易出问题。 + Instead you can mock the dependency, use a dummy value, or create a [spy](https://jasmine.github.io/2.0/introduction.html#section-Spies) on the pertinent service method. +你可以改用模拟依赖的方式，你可以使用虚值或在相关的服务方法上创建一个[间谍（spy）](https://jasmine.github.io/2.0/introduction.html#section-Spies)。 +
Prefer spies as they are usually the easiest way to mock services. +优先使用间谍，因为它们通常是 Mock 服务时最简单的方式。 +
These standard testing techniques are great for unit testing services in isolation. +这些标准的测试技巧对于在隔离的环境下对服务进行单元测试非常重要。 + However, you almost always inject service into application classes using Angular dependency injection and you should have tests that reflect that usage pattern. Angular testing utilities make it easy to investigate how injected services behave. +不过，你几乎迟早要用 Angular 的依赖注入机制来把服务注入到应用类中去，而且你应该已经有了这类测试。 +Angular 的测试工具集可以让你轻松探查这种注入服务的工作方式。 + #### Testing services with the _TestBed_ +#### 使用 `TestBed`（测试机床）测试服务 + Your app relies on Angular [dependency injection (DI)](guide/dependency-injection) to create services. When a service has a dependent service, DI finds or creates that dependent service. And if that dependent service has its own dependencies, DI finds-or-creates them as well. +你的应用中会依赖 Angular 的[依赖注入 (DI)](guide/dependency-injection) 来创建服务。 +当某个服务依赖另一个服务时，DI 就会找到或创建那个被依赖的服务。 +如果那个被依赖的服务还有它自己的依赖，DI 也同样会找到或创建它们。 + As service _consumer_, you don't worry about any of this. You don't worry about the order of constructor arguments or how they're created. +作为服务的*消费方*，你不需要关心这些细节。 +你不用关心构造函数中的参数顺序或如何创建它们。 + As a service _tester_, you must at least think about the first level of service dependencies but you _can_ let Angular DI do the service creation and deal with constructor argument order when you use the `TestBed` testing utility to provide and create services. +但对于服务的*测试方*来说，你就至少要考虑服务的第一级依赖了。 +不过你*可以*让 Angular DI 来负责服务的创建工作，但当你使用 `TestBed` 测试工具来提供和创建服务时，你仍然需要关心构造函数中的参数顺序。 + {@a testbed} #### Angular _TestBed_ @@ -169,11 +270,18 @@ The `TestBed` is the most important of the Angular testing utilities. The `TestBed` creates a dynamically-constructed Angular _test_ module that emulates an Angular [@NgModule](guide/ngmodules). +`TestBed` 是 Angular 测试工具中最重要的部分。 +`TestBed` 会动态创建一个用来模拟 [@NgModule](guide/ngmodules) 的 Angular *测试*模块。 + The `TestBed.configureTestingModule()` method takes a metadata object that can have most of the properties of an [@NgModule](guide/ngmodules). +`TestBed.configureTestingModule()` 方法接收一个元数据对象，其中具有 [@NgModule](guide/ngmodules) 中的绝大多数属性。 + To test a service, you set the `providers` metadata property with an array of the services that you'll test or mock. +要测试某个服务，就要在元数据的 `providers` 属性中指定一个将要进行测试或模拟的相关服务的数组。 + @@ -191,6 +301,8 @@ Then inject it inside a test by calling `TestBed.get()` with the service class a Or inside the `beforeEach()` if you prefer to inject the service as part of your setup. +或者，如果你更倾向于把该服务作为环境准备过程的一部分，就把它放在 `beforeEach()` 中。 + @@ -199,8 +311,12 @@ Or inside the `beforeEach()` if you prefer to inject the service as part of your When testing a service with a dependency, provide the mock in the `providers` array. +如果要测试一个带有依赖项的服务，那就把模拟对象放在 `providers` 数组中。 + In the following example, the mock is a spy object. +在下面的例子中，模拟对象是一个间谍（spy）对象。 + @@ -209,6 +325,8 @@ In the following example, the mock is a spy object. The test consumes that spy in the same way it did earlier. +该测试会像以前一样消费这个间谍对象。 + @@ -219,16 +337,26 @@ The test consumes that spy in the same way it did earlier. #### Testing without _beforeEach()_ +#### 不使用 `beforeEach` 进行测试 + Most test suites in this guide call `beforeEach()` to set the preconditions for each `it()` test and rely on the `TestBed` to create classes and inject services. +本指南中的大多数的测试套件都会调用 `beforeEach()` 来为每个 `it()` 测试设置前置条件，并依赖 `TestBed` 来创建类和注入服务。 + There's another school of testing that never calls `beforeEach()` and and prefers to create classes explicitly rather than use the `TestBed`. +另一些测试教程中也可能让你不要调用 `beforeEach()`，并且更倾向于显式创建类，而不要借助 `TestBed`。 + Here's how you might rewrite one of the `MasterService` tests in that style. +下面的例子教你如何把 `MasterService` 的测试改写成那种风格。 + Begin by putting re-usable, preparatory code in a _setup_ function instead of `beforeEach()`. +通过把可复用的准备代码放进一个单独的 `setup` 函数来代替 `beforeEach()`。 + @@ -254,6 +387,9 @@ Notice how the test uses [_destructuring assignment_](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) to extract the setup variables that it needs. +注意这些测试是如何使用 [解构赋值](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) +来提取出所需变量的。 + @@ -263,19 +399,30 @@ to extract the setup variables that it needs. Many developers feel this approach is cleaner and more explicit than the traditional `beforeEach()` style. +很多开发者觉得这种方式相比传统的 `beforeEach()` 风格更加干净、更加明确。 + Although this testing guide follows the tradition style and the default [CLI schematics](https://github.com/angular/devkit) generate test files with `beforeEach()` and `TestBed`, feel free to adopt _this alternative approach_ in your own projects. +虽然本章会遵循传统的风格，并且 [CLI](https://github.com/angular/devkit) 生成的默认测试文件也用的是 +`beforeEach()` 和 `TestBed`，不过你可以在自己的项目中自由选择*这种可选方式*。 + #### Testing HTTP services +#### 测试 HTTP 服务 + Data services that make HTTP calls to remote servers typically inject and delegate to the Angular [`HttpClient`](guide/http) service for XHR calls. +那些会向远端服务器发起 HTTP 调用的数据服务，通常会注入 Angular 的 [`HttpClient`](guide/http) 服务并委托它进行 XHR 调用。 + You can test a data service with an injected `HttpClient` spy as you would test any service with a dependency. +你可以像测试其它带依赖的服务那样，通过注入一个 `HttpClient` 间谍来测试这种数据服务。 + #### _HttpClientTestingModule_ @@ -302,42 +456,67 @@ the test runner will likely attribute to a completely different test. Extended interactions between a data service and the `HttpClient` can be complex and difficult to mock with spies. +如果将来 `HttpClient` 和数据服务之间有更多的交互，则可能会变得复杂，而且难以使用间谍进行模拟。 + The `HttpClientTestingModule` can make these testing scenarios more manageable. +`HttpClientTestingModule` 可以让这些测试场景变得更加可控。 + While the _code sample_ accompanying this guide demonstrates `HttpClientTestingModule`, this page defers to the [Http guide](guide/http#testing-http-requests), which covers testing with the `HttpClientTestingModule` in detail. +本章的*代码范例*要示范的是 `HttpClientTestingModule`，所以把部分内容移到了 [HttpClient 中](guide/http#testing-http-requests)，那里会详细讲解如何用 `HttpClientTestingModule` 进行测试。 +
This guide's sample code also demonstrates testing of the _legacy_ `HttpModule` in `app/model/http-hero.service.spec.ts`. +本章范例代码中的 `app/model/http-hero.service.spec.ts` 还示范了如何使用*传统的* `HttpModule` 进行验证。 +
## Component Test Basics +## 组件测试基础 + A component, unlike all other parts of an Angular application, combines an HTML template and a TypeScript class. The component truly is the template and the class _working together_. and to adequately test a component, you should test that they work together as intended. +组件与 Angular 应用中的其它部分不同，它是由 HTML 模板和 TypeScript 类组成的。 +组件其实是指模板加上与其合作的类。 +要想对组件进行充分的测试，就要测试它们能否如预期的那样协作。 + Such tests require creating the component's host element in the browser DOM, as Angular does, and investigating the component class's interaction with the DOM as described by its template. +这些测试需要在浏览器的 DOM 中创建组件的宿主元素（就像 Angular 所做的那样），然后检查组件类和 DOM 的交互是否如同它在模板中所描述的那样。 + The Angular `TestBed` facilitates this kind of testing as you'll see in the sections below. But in many cases, _testing the component class alone_, without DOM involvement, can validate much of the component's behavior in an easier, more obvious way. +Angular 的 `TestBed` 为所有这些类型的测试提供了基础设施。 +但是很多情况下，可以*单独测试组件类本身*而不必涉及 DOM，就已经可以用一种更加简单、清晰的方式来验证该组件的大多数行为了。 + ### Component class testing +### 单独测试组件类 + Test a component class on its own as you would test a service class. +你可以像测试服务类一样测试组件类。 + Consider this `LightswitchComponent` which toggles a light on and off (represented by an on-screen message) when the user clicks the button. +考虑下面这个 `LightswitchComponent`，当用户点击按钮时，它会切换灯的开关状态（用屏幕上的消息展现出来）。 + ng generate component banner --inline-template --inline-style --module app @@ -474,6 +709,8 @@ ng generate component banner --inline-template --inline-style --module app It also generates an initial test file for the component, `banner-external.component.spec.ts`, that looks like this: +它也会为组件生成最初的测试文件 `banner-external.component.spec.ts`，代码如下： + @@ -513,10 +761,16 @@ There's no need to declare or import anything else. The default test module is pre-configured with something like the `BrowserModule` from `@angular/platform-browser`. +不用声明或导入任何其它的东西。 +默认的测试模块中已经预先配置好了一些东西，比如来自 `@angular/platform-browser` 的 `BrowserModule`。 + Later you'll call `TestBed.configureTestingModule()` with imports, providers, and more declarations to suit your testing needs. Optional `override` methods can further fine-tune aspects of the configuration. +稍后你将会调用带有导入模块、服务提供商和更多可声明对象的 `TestBed.configureTestingModule()` 来满足测试所需。 +将来还可以用可选的 `override` 方法对这些配置进行微调。 + {@a create-component} @@ -525,6 +779,8 @@ Optional `override` methods can further fine-tune aspects of the configuration. After configuring `TestBed`, you call its `createComponent()` method. +在配置好 `TestBed` 之后，你还可以调用它的 `createComponent()` 方法。 + @@ -535,19 +791,27 @@ After configuring `TestBed`, you call its `createComponent()` method. adds a corresponding element to the test-runner DOM, and returns a [`ComponentFixture`](#component-fixture). +`TestBed.createComponent()` 会创建一个 `BannerComponent` 的实例，把相应的元素添加到测试运行器的 DOM 中，然后返回一个 [`ComponentFixture`](#component-fixture) 对象。 +
Do not re-configure `TestBed` after calling `createComponent`. -在调用了`createComponent`之后就不要再重新配置`TestBed`了。 +在调用了`createComponent`之后就不能再重新配置`TestBed`了。 The `createComponent` method freezes the current `TestBed`definition, closing it to further configuration. +`createComponent` 方法冻结了当前的 `TestBed` 定义，关闭它才能再进行后续配置。 + You cannot call any more `TestBed` configuration methods, not `configureTestingModule()`, nor `get()`, nor any of the `override...` methods. If you try, `TestBed` throws an error. +你不能再调用任何 `TestBed` 的后续配置方法了，不能调 `configureTestingModule()`、不能调 `get()`， +也不能调用任何 `override...` 方法。 +如果试图这么做，`TestBed` 就会抛出错误。 +
{@a component-fixture} @@ -556,8 +820,12 @@ If you try, `TestBed` throws an error. The [ComponentFixture](api/core/testing/ComponentFixture) is a test harness for interacting with the created component and its corresponding element. +[ComponentFixture](api/core/testing/ComponentFixture) 是一个测试挽具（就像马车缰绳），用来与所创建的组件及其 DOM 元素进行交互。 + Access the component instance through the fixture and confirm it exists with a Jasmine expectation: +可以通过测试夹具（fixture）来访问该组件的实例，并用 Jasmine 的 `expect` 语句来确保其存在。 + @@ -570,6 +838,9 @@ You will add more tests as this component evolves. Rather than duplicate the `TestBed` configuration for each test, you refactor to pull the setup into a Jasmine `beforeEach()` and some supporting variables: +随着该组件的成长，你将会添加更多测试。 +除了为每个测试都复制一份 `TestBed` 测试之外，你还可以把它们重构成 Jasmine 的 `beforeEach()` 中的设置语句以及一些支持性变量： + @@ -593,21 +866,33 @@ looks for the expected text. The value of `ComponentFixture.nativeElement` has the `any` type. Later you'll encounter the `DebugElement.nativeElement` and it too has the `any` type. +`ComponentFixture.nativeElement` 的值是 `any` 类型的。 +稍后你将遇到的 `DebugElement.nativeElement` 也同样是 `any` 类型的。 + Angular can't know at compile time what kind of HTML element the `nativeElement` is or if it even is an HTML element. The app might be running on a _non-browser platform_, such as the server or a [Web Worker](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API), where the element may have a diminished API or not exist at all. +Angular 在编译期间没办法知道 `nativeElement` 是哪种 HTML 元素，甚至是否 HTML 元素（译注：比如可能是 SVG 元素）。 +本应用还可能运行在*非浏览器平台上*，比如服务端渲染或 [Web Worker](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API) 那里的元素可能只有一些缩水过的 API，甚至根本不存在。 + The tests in this guide are designed to run in a browser so a `nativeElement` value will always be an `HTMLElement` or one of its derived classes. +本指南中的例子都是为运行在浏览器中而设计的，因此 `nativeElement` 的值一定会是 `HTMLElement` 及其派生类。 + Knowing that it is an `HTMLElement` of some sort, you can use the standard HTML `querySelector` to dive deeper into the element tree. +如果知道了它是某种 `HTMLElement`，你就可以用标准的 `querySelector` 在元素树中进行深挖了。 + Here's another test that calls `HTMLElement.querySelector` to get the paragraph element and look for the banner text: +下面这个测试就会调用 `HTMLElement.querySelector` 来获取 `

` 元素，并在其中查找 Banner 文本： + @@ -620,6 +905,8 @@ Here's another test that calls `HTMLElement.querySelector` to get the paragraph The Angular _fixture_ provides the component's element directly through the `fixture.nativeElement`. +Angular 的*夹具*可以通过 `fixture.nativeElement` 直接提供组件的元素。 + @@ -628,6 +915,8 @@ The Angular _fixture_ provides the component's element directly through the `fix This is actually a convenience method, implemented as `fixture.debugElement.nativeElement`. +它实际上是 `fixture.debugElement.nativeElement` 的一个便利方法。 + @@ -636,20 +925,34 @@ This is actually a convenience method, implemented as `fixture.debugElement.nati There's a good reason for this circuitous path to the element. +这种访问元素的迂回方式有很好的理由。 + The properties of the `nativeElement` depend upon the runtime environment. You could be running these tests on a _non-browser_ platform that doesn't have a DOM or whose DOM-emulation doesn't support the full `HTMLElement` API. +`nativeElement` 的属性取决于运行环境。 +你可以在没有 DOM，或者其 DOM 模拟器无法支持全部 `HTMLElement` API 的平台上运行这些测试。 + Angular relies on the `DebugElement` abstraction to work safely across _all supported platforms_. Instead of creating an HTML element tree, Angular creates a `DebugElement` tree that wraps the _native elements_ for the runtime platform. The `nativeElement` property unwraps the `DebugElement` and returns the platform-specific element object. +Angular 依赖于 `DebugElement` 这个抽象层，就可以安全的横跨*其支持的所有平台*。 +Angular 不再创建 HTML 元素树，而是创建 `DebugElement` 树，其中包裹着相应运行平台上的*原生元素*。 +`nativeElement` 属性会解开 `DebugElement`，并返回平台相关的元素对象。 + Because the sample tests for this guide are designed to run only in a browser, a `nativeElement` in these tests is always an `HTMLElement` whose familiar methods and properties you can explore within a test. +因为本章的这些测试都设计为只运行在浏览器中，因此这些测试中的 `nativeElement` 总是 `HTMLElement`， +你可以在测试中使用那些熟悉的方法和属性进行浏览。 + Here's the previous test, re-implemented with `fixture.debugElement.nativeElement`: +下面是对上一个测试改用 `fixture.debugElement.nativeElement` 进行的重新实现： + @@ -659,8 +962,12 @@ Here's the previous test, re-implemented with `fixture.debugElement.nativeElemen The `DebugElement` has other methods and properties that are useful in tests, as you'll see elsewhere in this guide. +`DebugElement` 还有其它的方法和属性，它们在测试中也很有用，你将在本章的其它测试中看到它们。 + You import the `DebugElement` symbol from the Angular core library. +你要从 Angular 核心库中导入 `DebugElement` 符号。 + @@ -674,15 +981,25 @@ You import the `DebugElement` symbol from the Angular core library. Although the tests in this guide all run in the browser, some apps might run on a different platform at least some of the time. +虽然本章中的测试都是运行在浏览器中的，不过有些应用可能会运行在其它平台上（至少一部分时间是这样）。 + For example, the component might render first on the server as part of a strategy to make the application launch faster on poorly connected devices. The server-side renderer might not support the full HTML element API. If it doesn't support `querySelector`, the previous test could fail. +比如，作为加快慢速网络设备上应用启动速度的一种策略，组件可能要先在服务器上渲染。服务端渲染可能无法支持完全的 HTML API。 +如果它不支持 `querySelector`，那么前一个测试就会失败。 + The `DebugElement` offers query methods that work for all supported platforms. These query methods take a _predicate_ function that returns `true` when a node in the `DebugElement` tree matches the selection criteria. +`DebugElement` 提供了可以工作在所有受支持的平台上的查询方法。 +这些查询方法接受一个谓词（predicate）函数，如果 `DebugElement` 树中的节点满足某个筛选条件，它就返回 `true`。 + You create a _predicate_ with the help of a `By` class imported from a library for the runtime platform. Here's the `By` import for the browser platform: +你可以在从库中导入的 `By` 类的帮助下为该运行平台创建谓词函数。下面这个 `By` 是从浏览器平台导入的： + @@ -692,6 +1009,8 @@ library for the runtime platform. Here's the `By` import for the browser platfor The following example re-implements the previous test with `DebugElement.query()` and the browser's `By.css` method. +下面这个例子使用 `DebugElement.query()` 和浏览器的 `By.css` 方法重新实现了前一个测试。 + @@ -700,33 +1019,56 @@ The following example re-implements the previous test with Some noteworthy observations: +值得注意的地方有： + * The `By.css()` static method selects `DebugElement` nodes with a [standard CSS selector](https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Getting_started/Selectors "CSS selectors"). + `By.css()` 静态方法使用[标准 CSS 选择器](https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Getting_started/Selectors "CSS selectors")选择了一些 `DebugElement` 节点。 + * The query returns a `DebugElement` for the paragraph. + 这次查询返回了 `

` 元素的一个 `DebugElement`。 + * You must unwrap that result to get the paragraph element. + 你必须解包此结果，以获取这个 `

` 元素。 + When you're filtering by CSS selector and only testing properties of a browser's _native element_, the `By.css` approach may be overkill. +当你要通过 CSS 选择器过滤，并且只打算测试浏览器的*原生元素*的属性时，`By.css` 这种方法就有点多余了。 + It's often easier and more clear to filter with a standard `HTMLElement` method such as `querySelector()` or `querySelectorAll()`, as you'll see in the next set of tests. +使用标准的 `HTMLElement` 方法，比如 `querySelector()` 或 `querySelectorAll()` 通常会更简单、更清晰。 +你在下一组测试中就会体会到这一点。 +

## Component Test Scenarios +## 组件测试场景 + The following sections, comprising most of this guide, explore common component testing scenarios +下面这些部分构成了本指南的大部分内容，它们将探讨一些常见的组件测试场景。 + ### Component binding +### 组件绑定 + The current `BannerComponent` presents static title text in the HTML template. +当前的 `BannerComponent` 在 HTML 模板中展示了静态标题内容。 + After a few changes, the `BannerComponent` presents a dynamic title by binding to the component's `title` property like this. +稍作修改之后，`BannerComponent` 也可以通过绑定到组件的 `title` 属性来展示动态标题。就像这样： + ` + You'll write a sequence of tests that inspect the value of the `

` element that wraps the _title_ property interpolation binding. +你将会写一系列测试来探查 `

` 元素的值，这个值包含在了带有 `title` 属性的插值表达式绑定中。 + You update the `beforeEach` to find that element with a standard HTML `querySelector` and assign it to the `h1` variable. +你要修改 `beforeEach` 来使用标准的 HTML `querySelector` 来找到钙元素，并把它赋值给 `h1` 变量。 + ` like this: +你的第一个测试希望看到屏幕显示出了默认的 `title`。 +你本能的写出如下测试来立即审查这个 `

` 元素： + @@ -767,6 +1122,8 @@ Your instinct is to write a test that immediately inspects the `

` like this: _That test fails_ with the message: +但*测试失败了*，给出如下信息： + ```javascript expected '' to contain 'Test Tour of Heroes'. @@ -775,15 +1132,20 @@ expected '' to contain 'Test Tour of Heroes'. Binding happens when Angular performs **change detection**. +因为绑定是在 Angular 执行**变更检测**时才发生的。 + In production, change detection kicks in automatically when Angular creates a component or the user enters a keystroke or an asynchronous activity (e.g., AJAX) completes. -在产品阶段，当Angular创建组件、用户输入或者异步动作（比如AJAX）完成时，自动触发变更检测。 +在产品阶段，当Angular创建组件、用户输入或者异步动作（比如AJAX）完成时，会自动触发变更检测。 The `TestBed.createComponent` does _not_ trigger change detection. a fact confirmed in the revised test: +但 `TestBed.createComponent` *不能*触发变更检测。 +可以在这个修改后的测试中确定这一点： + @@ -794,6 +1156,9 @@ a fact confirmed in the revised test: You must tell the `TestBed` to perform data binding by calling `fixture.detectChanges()`. Only then does the `

` have the expected title. +你必须通过调用 `fixture.detectChanges()` 来要求 `TestBed` 执行数据绑定。 +然后 `

` 中才会具有所期望的标题。 + @@ -804,8 +1169,13 @@ Delayed change detection is intentional and useful. It gives the tester an opportunity to inspect and change the state of the component _before Angular initiates data binding and calls [lifecycle hooks](guide/lifecycle-hooks)_. +这种迟到的变更检测是故意设计的，而且很有用。 +它给了测试者一个机会，*在 Angular 初始化数据绑定以及调用[生命周期钩子](guide/lifecycle-hooks)之前*探查并改变组件的状态。 + Here's another test that changes the component's `title` property _before_ calling `fixture.detectChanges()`. +下面这个测试中，会在调用 `fixture.detectChanges()` *之前*修改组件的 `title` 属性。 + @@ -816,12 +1186,20 @@ Here's another test that changes the component's `title` property _before_ calli #### Automatic change detection +#### 自动变更检测 + The `BannerComponent` tests frequently call `detectChanges`. Some testers prefer that the Angular test environment run change detection automatically. +`BannerComponent` 的这些测试需要频繁调用 `detectChanges`。 +有些测试者更喜欢让 Angular 测试环境自动运行变更检测。 + That's possible by configuring the `TestBed` with the `ComponentFixtureAutoDetect` provider. First import it from the testing utility library: +使用 `ComponentFixtureAutoDetect` 服务提供商来配置 `TestBed` 就可以做到这一点。 +首先从测试工具库中导入它： + Then add it to the `providers` array of the testing module configuration: @@ -846,7 +1224,7 @@ The `ComponentFixtureAutoDetect` service responds to _asynchronous activities_ s But a direct, synchronous update of the component property is invisible. The test must call `fixture.detectChanges()` manually to trigger another cycle of change detection. -第二和第三个测试程序显示了一个重要的局限性。 +第二和第三个测试程序显示了它重要的局限性。 Angular测试环境**不会**知道测试程序改变了组件的`title`属性。 自动检测只对异步行为比如承诺的解析、计时器和DOM事件作出反应。 但是直接修改组件属性值的这种同步更新是不会触发**自动检测**的。 @@ -858,8 +1236,8 @@ Rather than wonder when the test fixture will or won't perform change detection, the samples in this guide _always call_ `detectChanges()` _explicitly_. There is no harm in calling `detectChanges()` more often than is strictly necessary. -与其怀疑测试工具会不会执行变更检测，本章中的例子**总是显式**调用`detectChanges()`。 -即使是在不需要的时候，频繁调用`detectChanges()`没有任何什么坏处。 +相比于受测试工具有没有执行变更检测的困扰，本章中的例子更愿意**总是显式**调用 `detectChanges()`。 +即使是在不需要的时候，频繁调用 `detectChanges()` 也没有任何坏处。 @@ -867,12 +1245,18 @@ There is no harm in calling `detectChanges()` more often than is strictly necess ### Component with external files +### 带有外部文件的组件 + The `BannerComponent` above is defined with an _inline template_ and _inline css_, specified in the `@Component.template` and `@Component.styles` properties respectively. +上面的 `BannerComponent` 定义了一个*内联模板*和*内联 CSS*，分别是在 `@Component.template` 和 `@Component.styles` 属性中指定的。 + Many components specify _external templates_ and _external css_ with the `@Component.templateUrl` and `@Component.styleUrls` properties respectively, as the following variant of `BannerComponent` does. +很多组件会分别用 `@Component.templateUrl` 和 `@Component.styleUrls` 属性来指定*外部模板*和*外部 CSS*，就像下面这个 `BannerComponent` 的变体中所做的一样： + Error: This test module uses the component BannerComponent @@ -900,12 +1291,18 @@ Please call "TestBed.compileComponents" before your test. You get this test failure message when the runtime environment compiles the source code _during the tests themselves_. +如果在*测试自身期间*，运行环境试图编译源码，就会出现这个测试错误信息。 + To correct the problem, call `compileComponents()` as explained [below](#compile-components). +要解决这个问题，可以像[稍后](#compile-components)解释的那样调用一次 `compileComponents()`。 + {@a component-with-dependency} ### Component with a dependency +### 带依赖的组件 + Components often have service dependencies. 组件经常依赖其他服务。 @@ -920,6 +1317,9 @@ It knows who the user is based on a property of the injected `UserService`: The `WelcomeComponent` has decision logic that interacts with the service, logic that makes this component worth testing. Here's the testing module configuration for the spec file, `app/welcome/welcome.component.spec.ts`: +`WelcomeComponent` 带有与服务交互的决策逻辑，这些逻辑让该组件值得测试。 +下面是 `app/welcome/welcome.component.spec.ts` 中的测试模块配置： + This time, in addition to declaring the _component-under-test_, @@ -932,13 +1332,15 @@ But not the real `UserService`. #### Provide service test doubles +#### 提供服务的测试替身 + A _component-under-test_ doesn't have to be injected with real services. In fact, it is usually better if they are test doubles (stubs, fakes, spies, or mocks). The purpose of the spec is to test the component, not the service, and real services can be trouble. -被测试的组件不一定要注入真正的服务。实际上，服务的替身（stubs, fakes, spies或者mocks）通常会更加合适。 -spec的主要目的是测试组件，而不是服务。真实的服务可能自身有问题。 +被测试的组件不一定要注入真正的服务。实际上，服务的替身（Stub - 桩, Fake - 假冒品, Spy - 间谍或者 Mock - 模拟对象）通常会更加合适。 +spec 的主要目的是测试组件，而不是服务。真实的服务可能连自身都有问题，不应该让它干扰对组件的测试。 Injecting the real `UserService` could be a nightmare. The real service might ask the user for login credentials and @@ -952,6 +1354,8 @@ It is far easier and safer to create and register a test double in place of the This particular test suite supplies a minimal mock of the `UserService` that satisfies the needs of the `WelcomeComponent` and its tests: +这个测试套件提供了 `UserService` 的一个最小化模拟对象，它能满足 `WelcomeComponent` 及其测试的需求： + {@a service-from-injector} #### Always get the service from an injector +#### 总是从注入其中获取服务 + Do _not_ reference the `userServiceStub` object that's provided to the testing module in the body of your test. **It does not work!** @@ -1033,8 +1449,12 @@ a clone of the provided `userServiceStub`. #### Final setup and tests +#### 最终的设置及测试代码 + Here's the complete `beforeEach()`, using `TestBed.get()`: +下面是使用 `TestBed.get()` 的完整的 `beforeEach()`： + And here are some tests: @@ -1053,6 +1473,10 @@ The second parameter to the Jasmine matcher (e.g., `'expected name'`) is an opti If the expectation fails, Jasmine displays appends this label to the expectation failure message. In a spec with multiple expectations, it can help clarify what went wrong and which expectation failed. +Jasmine 匹配器的第二个参数（比如 `'expected name'`）是一个可选的失败标签。 +如果这个期待语句失败了，Jasmine 就会把这个标签追加到这条个期待语句的失败信息后面。 +对于具有多个期待语句的规约，它可以帮助澄清到底什么出错了，以及哪个期待语句失败了。 + The remaining tests confirm the logic of the component when the service returns different values. @@ -1069,9 +1493,14 @@ The third test checks that the component displays the proper message when there ### Component with async service +### 带有异步服务的组件 + In this sample, the `AboutComponent` template hosts a `TwainComponent`. The `TwainComponent` displays Mark Twain quotes. +在这个例子中，`AboutComponent` 的模板中还有一个 `TwainComponent`。 +`TwainComponent` 用于显示引自马克·吐温的话。 + @@ -1130,15 +1580,24 @@ The spy is designed such that any call to `getQuote` receives an Observable with Unlike the real `getQuote()` method, this spy bypasses the server and returns a synchronous Observable whose value is available immediately. +这个间谍的设计是：任何对 `getQuote` 的调用都会收到一个包含测试引文的可观察对象。 +和真正的 `getQuote()` 方法不同，这个间谍跳过了服务器，直接返回了一个能立即解析出值的同步型可观察对象。 + You can write many useful tests with this spy, even though its `Observable` is synchronous. +虽然它的 `Observable` 是同步的，不过你仍然可以使用这个间谍对象写出很多有用的测试。 + {@a sync-tests} #### Synchronous tests +#### 同步测试 + A key advantage of a synchronous `Observable` is that you can often turn asynchronous processes into synchronous tests. +同步 `Observable` 的一大优点就是你可以把那些异步的流程转换成同步测试。 + @@ -1149,18 +1608,28 @@ Because the spy result returns synchronously, the `getQuote()` method updates the message on screen immediately _after_ the first change detection cycle during which Angular calls `ngOnInit`. +因为间谍对象的结果是同步返回的，所以 `getQuote()` 方法会在 Angular 调用 `ngOnInit` 时触发的首次变更检测周期后立即修改屏幕上的消息。 + You're not so lucky when testing the error path. Although the service spy will return an error synchronously, the component method calls `setTimeout()`. The test must wait at least one full turn of the JavaScript engine before the value becomes available. The test must become _asynchronous_. +但测试出错路径的时候就没这么幸运了。 +虽然该服务的间谍也会返回一个同步的错误对象，但是组件的那个方法中调用了 `setTimeout()`。 +这个测试必须至少等待 JavaScript 引擎的一个周期，那个值才会变成可用状态。因此这个测试变成了*异步的*。 + {@a fake-async} #### Async test with _fakeAsync()_ +#### 使用 `fakeAsync()` 进行异步测试 + The following test confirms the expected behavior when the service returns an `ErrorObservable`. +下列测试用于确保当服务返回 `ErrorObservable` 的时候也能有符合预期的行为。 + @@ -1169,6 +1638,8 @@ The following test confirms the expected behavior when the service returns an `E Note that the `it()` function receives an argument of the following form. +注意这个 `it()` 函数接收了一个如下形式的参数。 + ```javascript fakeAsync(() => { /* test body */ })` @@ -1179,30 +1650,54 @@ The `fakeAsync` function enables a linear coding style by running the test body The test body appears to be synchronous. There is no nested syntax (like a `Promise.then()`) to disrupt the flow of control. +`fakeAsync` 函数通过在一个特殊的*`fakeAsync`测试区域（zone）*中运行测试体来启用线性代码风格。 +测试体看上去是同步的。 +这里没有嵌套式语法（如`Promise.then()`）来打断控制流。 + {@a tick} #### The _tick()_ function +#### `tick()` 函数 + You do have to call `tick()` to advance the (virtual) clock. +你必须调用 `tick()` 函数来向前推动（虚拟）时钟。 + Calling `tick()` simulates the passage of time until all pending asynchronous activities finish. In this case, it waits for the error handler's `setTimeout()`; +调用 `tick()` 会模拟时光的流逝，直到所有未决的异步活动都结束为止。 +在这个例子中，它会等待错误处理器中的 `setTimeout()`。 + The `tick` function is one of the Angular testing utilities that you import with `TestBed`. It's a companion to `fakeAsync` and you can only call it within a `fakeAsync` body. +`tick` 函数是你通过 `TestBed` 中引入的 Angular 测试工具集之一。 +它总是和 `fakeAsync` 一起使用，你也只能在 `fakeAsync` 的函数体中调用它。 + #### Async observables +#### 异步的可观察对象 + You might be satisfied with the test coverage of these tests. +你可能对这些测试的覆盖率已经很满足了。 + But you might be troubled by the fact that the real service doesn't quite behave this way. The real service sends requests to a remote server. A server takes time to respond and the response certainly won't be available immediately as in the previous two tests. +不过你可能会因为真实的服务没有按这种方式工作而困扰。 +真实的服务器会把请求发送给远端服务器。 +服务需要花一些时间来作出响应，它的响应当然也不会真的像前面两个测试中那样立即可用。 + Your tests will reflect the real world more faithfully if you return an _asynchronous_ observable from the `getQuote()` spy like this. +如果你在 `getQuote()` 间谍中返回一个*异步*可观察对象，那它就能更忠诚的反映出真实的世界了。 + @@ -1211,10 +1706,15 @@ from the `getQuote()` spy like this. #### Async observable helpers +#### 可观察对象的异步助手 + The async observable was produced by an `asyncData` helper The `asyncData` helper is a utility function that you'll have to write yourself. Or you can copy this one from the sample code. +这个异步的可观察对象是用 `asyncData` 辅助函数生成的。 +`asyncData` 助手是一个工具函数，你可以自己写一个，也可以从下面的范例代码中复制一份。 + @@ -1243,12 +1754,18 @@ There's a similar helper for producing an async error. #### More async tests +#### 更多异步测试 + Now that the `getQuote()` spy is returning async observables, most of your tests will have to be async as well. +现在，`getQuote()` 间谍会返回一个异步的可观察对象，你的大多数测试也同样要变成异步的。 + Here's a `fakeAsync()` test that demonstrates the data flow you'd expect in the real world. +下面这个 `fakeAsync()` 测试演示了你所期待的和真实世界中一样的数据流。 + @@ -1258,31 +1775,51 @@ in the real world. Notice that the quote element displays the placeholder value (`'...'`) after `ngOnInit()`. The first quote hasn't arrived yet. +注意，这个 `` 元素应该在 `ngOnInit()` 之后显示占位值（`'...'`）， +但第一个引文却没有出现。 + To flush the first quote from the observable, you call `tick()`. Then call `detectChanges()` to tell Angular to update the screen. +要刷出可观察对象中的第一个引文，你就要先调用 `tick()`，然后调用 `detectChanges()` 来要求 Angular 刷新屏幕。 + Then you can assert that the quote element displays the expected text. +然后你就可以断言这个 `` 元素应该显示所预期的文字了。 + {@a async} #### Async test with _async()_ +#### 使用 `async()` 进行异步测试 + The `fakeAsync()` utility function has a few limitations. In particular, it won't work if the test body makes an `XHR` call. +`fakeAsync()` 工具函数有一些限制。 +特别是，如果测试中发起了 `XHR` 调用，它就没用了。 + `XHR` calls within a test are rare so you can generally stick with `fakeAsync()`. But if you ever do need to call `XHR`, you'll want to know about `async()`. +测试中的 `XHR` 调用比较罕见，所以你通常会使用 `fakeAsync()`。 +不过你可能迟早会需要调用 `XHR`，那就来了解一些 `async()` 的知识吧。 +
The `TestBed.compileComponents()` method (see [below](#compile-components)) calls `XHR` to read external template and css files during "just-in-time" compilation. Write tests that call `compileComponents()` with the `async()` utility. +`TestBed.compileComponents()` 方法（参见[稍后](#compile-components)）就会在 JIT 编译期间调用 `XHR` 来读取外部模板和 CSS 文件。 +如果写调用了 `compileComponents()` 的测试，就要用到 `async()` 工具函数了。 +
Here's the previous `fakeAsync()` test, re-written with the `async()` utility. +下面是用 `async()` 工具函数重写的以前的 `fakeAsync()` 测试。 + @@ -1294,9 +1831,14 @@ to run in a special _async test zone_. You don't have to pass Jasmine's `done()` into the test and call `done()` in promise or observable callbacks. +`async()` 工具函数通过把测试人员的代码放进在一个特殊的*async 测试区域*中，节省了一些用于异步调用的样板代码。 +你不必把 Jasmine 的 `done()` 传给这个测试，并在承诺（Promise）或可观察对象的回调中调用 `done()`。 + But the test's asynchronous nature is revealed by the call to `fixture.whenStable()`, which breaks the linear flow of control. +但是对 `fixture.whenStable()` 的调用揭示了该测试的异步本性，它将会打破线性的控制流。 + {@a when-stable} #### _whenStable_ @@ -1304,13 +1846,21 @@ which breaks the linear flow of control. The test must wait for the `getQuote()` observable to emit the next quote. Instead of calling `tick()`, it calls `fixture.whenStable()`. +该测试必须等待 `getQuote()` 的可观察对象发出下一条引言。 +它不再调用 `tick()`，而是调用 `fixture.whenStable()`。 + The `fixture.whenStable()` returns a promise that resolves when the JavaScript engine's task queue becomes empty. In this example, the task queue becomes empty when the observable emits the first quote. +`fixture.whenStable()` 返回一个承诺，这个承诺会在 JavaScript 引擎的任务队列变为空白时被解析。 +在这个例子中，一旦这个可观察对象发出了第一条引言，这个任务队列就会变为空。 + The test resumes within the promise callback, which calls `detectChanges()` to update the quote element with the expected text. +该测试在这个承诺的回调中继续执行，它会调用 `detectChanges()` 来用预期的文本内容修改 `` 元素。 + {@a jasmine-done} #### Jasmine _done()_ @@ -1321,16 +1871,28 @@ you can still fall back to the traditional technique and pass `it` a function that takes a [`done` callback](http://jasmine.github.io/2.0/introduction.html#section-Asynchronous_Support). +虽然 `async` 和 `fakeAsync` 函数极大地简化了 Angular 的异步测试，不过你仍然可以回退到传统的技术中。 +也就是说给 `it` 额外传入一个函数型参数，这个函数接受一个 [`done` 回调](http://jasmine.github.io/2.0/introduction.html#section-Asynchronous_Support)。 + Now you are responsible for chaining promises, handling errors, and calling `done()` at the appropriate moments. +现在，你就要负责对 Promise 进行链接、处理错误，并在适当的时机调用 `done()` 了。 + Writing test functions with `done()`, is more cumbersome than `async`and `fakeAsync`. But it is occasionally necessary. For example, you can't call `async` or `fakeAsync` when testing code that involves the `intervalTimer()` or the RxJS `delay()` operator. +写带有 `done()` 的测试函数会比 `async` 和 `fakeAsync` 方式更加冗长。 +不过有些时候它是必要的。 +比如，你不能在那些涉及到 `intervalTimer()` 或 RxJS 的 `delay()` 操作符时调用 `async` 或 `fakeAsync` 函数。 + Here are two mover versions of the previous test, written with `done()`. The first one subscribes to the `Observable` exposed to the template by the component's `quote` property. +下面是对前面的测试用 `done()` 重写后的两个版本。 +第一个会订阅由组件的 `quote` 属性暴露给模板的那个 `Observable`。 + @@ -1341,12 +1903,19 @@ The RxJS `last()` operator emits the observable's last value before completing, The `subscribe` callback calls `detectChanges()` to update the quote element with the test quote, in the same manner as the earlier tests. +RxJS 的 `last()` 操作符会在结束之前发出这个可观察对象的最后一个值，也就是那条测试引文。 +`subscribe` 回调中会像以前一样调用 `detectChanges()` 用这条测试引文更新 `` 元素。 + In some tests, you're more interested in how an injected service method was called and what values it returned, than what appears on screen. +有些测试中，相对于在屏幕上展示了什么，你可能会更关心所注入服务的某个方法是如何被调用的，以及它的返回值是什么。 + A service spy, such as the `qetQuote()` spy of the fake `TwainService`, can give you that information and make assertions about the state of the view. +服务的间谍，比如假冒服务 `TwainService` 的 `getQuote()` 间谍，可以给你那些信息，并且对视图的状态做出断言。 + @@ -1359,15 +1928,24 @@ can give you that information and make assertions about the state of the view. ### Component marble tests +### 组件的宝石测试 + The previous `TwainComponent` tests simulated an asynchronous observable response from the `TwainService` with the `asyncData` and `asyncError` utilities. +前面的 `TwainComponent` 测试中使用 `TwainService` 中的 `asyncData` 和 `asyncError` 工具函数仿真了可观察对象的异步响应。 + These are short, simple functions that you can write yourself. Unfortunately, they're too simple for many common scenarios. An observable often emits multiple times, perhaps after a significant delay. A component may coordinate multiple observables with overlapping sequences of values and errors. +那些都是你自己写的简短函数。 +很不幸，它们对于很多常见场景来说都太过简单了。 +可观察对象通常会发出很多次值，还可能会在显著的延迟之后。 +组件可能要协调多个由正常值和错误值组成的重叠序列的可观察对象。 + **RxJS marble testing** is a great way to test observable scenarios, both simple and complex. You've likely seen the [marble diagrams](http://rxmarbles.com/) @@ -1375,12 +1953,20 @@ that illustrate how observables work. Marble testing uses a similar marble language to specify the observable streams and expectations in your tests. +**RxJS 的宝石测试**是测试各种可观察对象场景的最佳方式 —— 无论简单还是复杂。 +你可以看看[宝石图](http://rxmarbles.com/)，它揭示了可观察对象的工作原理。 +宝石测试使用类似的宝石语言来在你的测试中指定可观察对象流和对它们的期待。 + The following examples revisit two of the `TwainComponent` tests with marble testing. +下面的例子使用宝石测试重写了 `TwainComponent` 的两个测试。 + Start by installing the `jasmine-marbles` npm package. Then import the symbols you need. +首先安装 `jasmine-marbles` 这个 npm 包，然后倒入所需的符号。 + @@ -1400,12 +1988,19 @@ Notice that the Jasmine test is synchronous. There's no `fakeAsync()`. Marble testing uses a test scheduler to simulate the passage of time in a synchronous test. +注意，这个 Jasmine 测试是同步的。没有调用 `fakeAsync()`。 +宝石测试使用了一个测试调度程序来用同步的方式模拟时间的流逝。 + The beauty of marble testing is in the visual definition of the observable streams. This test defines a [_cold_ observable](#cold-observable) that waits three [frames](#marble-frame) (`---`), emits a value (`x`), and completes (`|`). In the second argument you map the value marker (`x`) to the emitted value (`testQuote`). +宝石测试的美妙之处在于它给出了可观察对象流的可视化定义。 +这个测试定义了一个[*冷的*可观察对象](#cold-observable)，它等待三[帧](#marble-frame) (`---`)，然后发出一个值（`x`），然后结束（`|`）。 +在第二个参数中，你把值标记（`x`）换成了实际发出的值（`testQuote`）。 + @@ -1415,9 +2010,13 @@ In the second argument you map the value marker (`x`) to the emitted value (`tes The marble library constructs the corresponding observable, which the test sets as the `getQuote` spy's return value. +这个宝石库会构造出相应的可观察对象，测试代码会把它当做 `getQuote` 间谍的返回值。 + When you're ready to activate the marble observables, you tell the `TestScheduler` to _flush_ its queue of prepared tasks like this. +当你已经准备好激活这个宝石库构造出的可观察对象时，只要让 `TestScheduler` 去*刷新*准备好的任务队列就可以了。代码如下： + @@ -1428,10 +2027,17 @@ This step serves a purpose analogous to `tick()` and `whenStable()` in the earlier `fakeAsync()` and `async()` examples. The balance of the test is the same as those examples. +这个步骤的目的类似于前面的 `fakeAsync()` 和 `async()` 范例中的 `tick()` 和 `whenStable()`。 +这种测试的权衡方式也和那些例子中是一样的。 + #### Marble error testing +#### 宝石错误测试 + Here's the marble testing version of the `getQuote()` error test. +下面是 `getQuote()` 错误测试的宝石测试版本。 + @@ -1441,8 +2047,12 @@ Here's the marble testing version of the `getQuote()` error test. It's still an async test, calling `fakeAsync()` and `tick()`, because the component itself calls `setTimeout()` when processing errors. +它仍然是异步测试，要调用 `fakeAsync()` 和 `tick()`，这是因为组件自身在处理错误的时候调用 `setTimeout()`。 + Look at the marble observable definition. +看看宝石库生成的可观察对象的定义。 + @@ -1453,33 +2063,54 @@ This is a _cold_ observable that waits three frames and then emits an error, The hash (`#`) indicates the timing of the error that is specified in the third argument. The second argument is null because the observable never emits a value. +它是一个*冷的*可观察对象，它等待三帧，然后发出一个错误。 +井号（`#`）标记出了发出错误的时间点，这个错误是在第三个参数中指定的。 +第二个参数是空的，因为这个可观察对象永远不会发出正常值。 + #### Learn about marble testing +#### 深入学习宝石测试 + {@a marble-frame} A _marble frame_ is a virtual unit of testing time. Each symbol (`-`, `x`, `|`, `#`) marks the passing of one frame. +*宝石帧*是测试时序中的虚拟单元。 +每个符号（`-`，`x`，`|`，`#`）都表示一帧过去了。 + {@a cold-observable} A _cold_ observable doesn't produce values until you subscribe to it. Most of your application observables are cold. All [_HttpClient_](guide/http) methods return cold observables. +*冷的*可观察对象不会生成值，除非你订阅它。 +应用中的大多数可观察对象都是冷的。 +所有 [`HttpClient`](guide/http)的方法返回的都是冷的可观察对象。 + A _hot_ observable is already producing values _before_ you subscribe to it. The [_Router.events_](api/router/Router#events) observable, which reports router activity, is a _hot_ observable. +*热的*可观察对象在你订阅它之前就会生成值。 +[`Router.events`](api/router/Router#events) 可观察对象会主动汇报路由器的活动，它就是个*热的*可观察对象。 + RxJS marble testing is a rich subject, beyond the scope of this guide. Learn about it on the web, starting with the [official documentation](https://github.com/ReactiveX/rxjs/blob/master/doc/writing-marble-tests.md). +RxJS 的宝石测试是一个内容丰富的主题，超出了本章的范围。 +要想在网络上进一步学习它，可以从 [official documentation](https://github.com/ReactiveX/rxjs/blob/master/doc/writing-marble-tests.md) 开始。 +
{@a component-with-input-output} ### 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 an event binding to listen to events raised by the output property. @@ -1581,8 +2212,12 @@ so, try the second and third options. #### Test _DashboardHeroComponent_ stand-alone +#### 单独测试 `DashboardHeroComponent` + Here's the meat of the spec file setup. +下面是 spec 文件的设置语句中的重点部分。 + @@ -1607,6 +2244,8 @@ The following test verifies that the hero name is propagated to the template via Because the [template](#dashboard-hero-component) passes the hero name through the Angular `UpperCasePipe`, the test must match the element value with the upper-cased name. +因为[模板](#dashboard-hero-component)通过 Angular 的 `UpperCasePipe` 传入了英雄的名字，所以这个测试必须匹配该元素的值中包含了大写形式的名字。 +
This small test demonstrates how Angular tests can verify a component's visual @@ -1614,13 +2253,20 @@ representation—something not possible with [component class tests](#component-class-testing)—at low cost and without resorting to much slower and more complicated end-to-end tests. +这个小测试示范了 Angular 的测试如何以较低的成本验证组件的视觉表现（它们不能通过[组件类测试](#component-class-testing)进行验证）。 +而不用借助那些更慢、更复杂的端到端测试。 +
#### Clicking +#### 点击 + Clicking the hero should raise a `selected` event that the host component (`DashboardComponent` presumably) can hear: +点击这个英雄将会发出一个 `selected` 事件，而宿主元素（可能是`DashboardComponent`）可能会听到它： + @@ -1631,21 +2277,34 @@ The component's `selected` property returns an `EventEmitter`, which looks like an RxJS synchronous `Observable` to consumers. The test subscribes to it _explicitly_ just as the host component does _implicitly_. +该组件的 `selected` 属性返回一个 `EventEmitter`，对消费者来说它和 RxJS 的同步 `Observable` 很像。 +该测试会*显式*订阅它，而宿主组件会*隐式*订阅它。 + If the component behaves as expected, clicking the hero's element should tell the component's `selected` property to emit the `hero` object. +如果该组件的行为符合预期，点击英雄所在的元素就会告诉组件的 `selected` 属性发出这个 `hero` 对象。 + The test detects that event through its subscription to `selected`. +这个测试会通过订阅 `selected` 来检测是否确实如此。 + {@a trigger-event-handler} #### _triggerEventHandler_ The `heroDe` in the previous test is a `DebugElement` that represents the hero `
`. +前面测试中的 `heroDe` 是一个指向英雄条目 `
` 的 `DebugElement`。 + It has Angular properties and methods that abstract interaction with the native element. This test calls the `DebugElement.triggerEventHandler` with the "click" event name. The "click" event binding responds by calling `DashboardHeroComponent.click()`. +它有一些用于抽象与原生元素交互的 Angular 属性和方法。 +这个测试会使用事件名称 `click` 来调用 `DebugElement.triggerEventHandler`。 +`click` 的事件绑定到了 `DashboardHeroComponent.click()`。 + 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. @@ -1654,6 +2313,8 @@ Angular的`DebugElement.triggerEventHandler`可以用**事件的名字**触发** The test triggered a "click" event with a `null` event object. +该测试使用事件对象 `null` 触发了一次 `click` 事件。 + @@ -1663,7 +2324,7 @@ 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()`方法——不关心事件对象。 +测试程序假设（在这里应该这样)运行时间的事件处理器（组件的`click()`方法）不关心事件对象。
@@ -1672,13 +2333,20 @@ directive expects an object with a `button` property that identifies which mouse button (if any) was pressed during the click. The `RouterLink` directive throws an error if the event object is missing. +其它处理器的要求比较严格。比如，`RouterLink` 指令期望一个带有 `button` 属性的对象，该属性用于指出点击时按下的是哪个鼠标按钮。 +如果不给出这个事件对象，`RouterLink` 指令就会抛出一个错误。 +
#### Click the element +#### 点击该元素 + The following test alternative calls the native element's own `click()` method, which is perfectly fine for _this component_. +下面这个测试改为调用原生元素自己的 `click()` 方法，它对于*这个组件*来说相当完美。 + @@ -1689,6 +2357,8 @@ which is perfectly fine for _this component_. #### _click()_ helper +#### _click()_ 辅助函数 + Clicking a button, an anchor, or an arbitrary HTML element is a common test task. 点击按钮、链接或者任意HTML元素是很常见的测试任务。 @@ -1696,6 +2366,8 @@ Clicking a button, an anchor, or an arbitrary HTML element is a common test task Make that consistent and easy by encapsulating the _click-triggering_ process in a helper such as the `click()` function below: +把*点击事件*的处理过程包装到如下的 `click()` 辅助函数中，可以让这项任务更一致、更简单： + This testing module configuration shows three important differences: +这个测试模块的配置信息有三个重要的不同点： + 1. It _declares_ both the `DashboardHeroComponent` and the `TestHostComponent`. 它同时**声明**了`DashboardHeroComponent`和`TestHostComponent`。 @@ -1787,6 +2484,8 @@ This testing module configuration shows three important differences: 1. The `TestHostComponent` sets the `DashboardHeroComponent.hero` with a binding. + `TestHostComponent` 通过绑定机制设置了 `DashboardHeroComponent.hero`。 + The `createComponent` returns a `fixture` that holds an instance of `TestHostComponent` instead of an instance of `DashboardHeroComponent`. `createComponent`返回的`fixture`里有`TestHostComponent`实例，而非`DashboardHeroComponent`组件实例。 @@ -1821,14 +2520,22 @@ really does find its way up through the event binding to the host component. ### Routing component +### 路由组件 + A _routing component_ is a component that tells the `Router` to navigate to another component. The `DashboardComponent` is a _routing component_ because the user can navigate to the `HeroDetailComponent` by clicking on one of the _hero buttons_ on the dashboard. +所谓*路由组件*就是指会要求 `Router` 导航到其它组件的组件。 +`DashboardComponent` 就是一个*路由组件*，因为用户可以通过点击仪表盘中的某个*英雄按钮*来导航到 `HeroDetailComponent`。 + Routing is pretty complicated. Testing the `DashboardComponent` seemed daunting in part because it involves the `Router`, which it injects together with the `HeroService`. +路由确实很复杂。 +测试 `DashboardComponent` 看上去有点令人生畏，因为它牵扯到和 `HeroService` 一起注入进来的 `Router`。 + The `HeroDetail` component needs the `id` parameter so it can fetch the corresponding hero via the `HeroDetailService`. +`HeroDetailComponent` 组件需要一个 `id` 参数，以便通过 `HeroDetailService` 获取相应的英雄。 + The component has to get the `id` from the `ActivatedRoute.paramMap` property which is an _Observable_. +该组件只能从 `ActivatedRoute.paramMap` 属性中获取这个 `id`，这个属性是一个 `Observable`。 + It can't just reference the `id` property of the `ActivatedRoute.paramMap`. The component has to _subscribe_ to the `ActivatedRoute.paramMap` observable and be prepared for the `id` to change during its lifetime. +它不能仅仅引用 `ActivatedRoute.paramMap` 的 `id` 属性。 +该组件不得不*订阅* `ActivatedRoute.paramMap` 这个可观察对象，要做好它在生命周期中随时会发生变化的准备。 +
The [Router](guide/router#route-parameters) guide covers `ActivatedRoute.paramMap` in more detail. +[路由与导航](guide/router#route-parameters)一章中详细讲解了 `ActivatedRoute.paramMap`。 +
Tests can explore how the `HeroDetailComponent` responds to different `id` parameter values by manipulating the `ActivatedRoute` injected into the component's constructor. +通过操纵注入到组件构造函数中的这个 `ActivatedRoute`，测试可以探查 `HeroDetailComponent` 是如何对不同的 `id` 参数值做出响应的。 + You know how to spy on the `Router` and a data service. +你已经知道了如何给 `Router` 和数据服务安插间谍。 + You'll take a different approach with `ActivatedRoute` because +不过对于 `ActivatedRoute`，你要采用另一种方式，因为： + * `paramMap` returns an `Observable` that can emit more than one value during a test. + 在测试期间，`paramMap` 会返回一个能发出多个值的 `Observable`。 + * You need the router helper function, `convertToParamMap()`, to create a `ParamMap`. + 你需要路由器的辅助函数 `convertToParamMap()` 来创建 `ParamMap`。 + * Other _routed components_ tests need a test double for `ActivatedRoute`. + 针对*路由目标组件*的其它测试需要一个 `ActivatedRoute` 的测试替身。 + These differences argue for a re-usable stub class. +这些差异表明你需要一个可复用的桩类（stub）。 + #### _ActivatedRouteStub_ The following `ActivatedRouteStub` class serves as a test double for `ActivatedRoute`. +下面的 `ActivatedRouteStub` 类就是作为 `ActivatedRoute` 类的测试替身使用的。 + Consider writing a more capable version of this stub class with the [_marble testing library_](#marble-testing). + 可以考虑使用[宝石测试库](#marble-testing)来为此测试桩编写一个更强力的版本。 +
{@a tests-w-test-double} #### Testing with _ActivatedRouteStub_ +#### 使用 `ActivatedRouteStub` 进行测试 + Here's a test demonstrating the component's behavior when the observed `id` refers to an existing hero: 下面的测试程序是演示组件在被观察的`id`指向现有英雄时的行为： @@ -1962,14 +2727,23 @@ Here's a test demonstrating the component's behavior when the observed `id` refe The `createComponent()` method and `page` object are discussed [below](#page-object). Rely on your intuition for now. +`createComponent()` 方法和 `page` 对象会在[稍后](#page-object)进行讨论。 +不过目前，你只要凭直觉来理解就行了。 +
When the `id` cannot be found, the component should re-route to the `HeroListComponent`. +当找不到 `id` 的时候，组件应该重新路由到 `HeroListComponent`。 + The test suite setup provided the same router spy [described above](#routing-component) which spies on the router without actually navigating. +测试套件的设置代码提供了一个和[前面](#routing-component)一样的路由器间谍，它会充当路由器的角色，而不用发起实际的导航。 + This test expects the component to try to navigate to the `HeroListComponent`. +这个测试中会期待该组件尝试导航到 `HeroListComponent`。 + While this app doesn't have a route to the `HeroDetailComponent` that omits the `id` parameter, it might add such a route someday. @@ -1995,14 +2769,22 @@ New heroes have `id=0` and a blank `name`. This test confirms that the component ### Nested component tests +### 对嵌套组件的测试 + Component templates often have nested components, whose templates may contain more components. +组件的模板中通常还会有嵌套组件，嵌套组件的模板还可能包含更多组件。 + The component tree can be very deep and, most of the time, the nested components play no role in testing the component at the top of the tree. +这棵组件树可能非常深，并且大多数时候在测试这棵树顶部的组件时，这些嵌套的组件都无关紧要。 + The `AppComponent`, for example, displays a navigation bar with anchors and their `RouterLink` directives. +比如，`AppComponent` 会显示一个带有链接及其 `RouterLink` 指令的导航条。 + @@ -2013,35 +2795,56 @@ While the `AppComponent` _class_ is empty, you may want to write unit tests to confirm that the links are wired properly to the `RouterLink` directives, perhaps for the reasons [explained below](#why-stubbed-routerlink-tests). +虽然 `AppComponent` *类*是空的，不过，由于[稍后解释的原因](#why-stubbed-routerlink-tests)，你可能会希望写个单元测试来确认这些链接是否正确使用了 `RouterLink` 指令。 + To validate the links, you don't need the `Router` to navigate and you don't need the `` to mark where the `Router` inserts _routed components_. +要想验证这些链接，你不必用 `Router` 进行导航，也不必使用 `` 来指出 `Router` 应该把*路由目标组件*插入到什么地方。 + The `BannerComponent` and `WelcomeComponent` (indicated by `` and ``) are also irrelevant. +而 `BannerComponent` 和 `WelcomeComponent`（写作 `` 和 ``）也同样风马牛不相及。 + Yet any test that creates the `AppComponent` in the DOM will also create instances of these three components and, if you let that happen, you'll have to configure the `TestBed` to create them. +然而，任何测试，只要能在 DOM 中创建 `AppComponent`，也就同样能创建这三个组件的实例。如果要创建它们，你就要配置 `TestBed`。 + If you neglect to declare them, the Angular compiler won't recognize the ``, ``, and `` tags in the `AppComponent` template and will throw an error. +如果你忘了声明它们，Angular 编译器就无法在 `AppComponent` 模板中识别出 ``、`` 和 `` 标记，并抛出一个错误。 + If you declare the real components, you'll also have to declare _their_ nested components and provide for _all_ services injected in _any_ component in the tree. +如果你声明的这些都是真实的组件，那么也同样要声明*它们*的嵌套组件，并要为这棵组件树中的*任何*组件提供要注入的*所有*服务。 + That's too much effort just to answer a few simple questions about links. +如果只是想回答有关链接的一些简单问题，做这些显然就太多了。 + This section describes two techniques for minimizing the setup. Use them, alone or in combination, to stay focused on the testing the primary component. +本节会讲减少此类设置工作的两项技术。 +单独使用或组合使用它们，可以让这些测试聚焦于要测试的主要组件上。 + {@a stub-component} ##### Stubbing unneeded components +##### 对不需要的组件提供桩（stub） + In the first technique, you create and declare stub versions of the components and directive that play little or no role in the tests. +这项技术中，你要为那些在测试中无关紧要的组件或指令创建和声明一些测试桩。 + ` element and the `routerLink` attribute because you declared a corresponding `AppComponent` and `RouterLinkDirectiveStub` in the `TestBed` configuration. +编译器将会识别出 `` 元素和 `RouterLink` 属性，因为你在 `TestBed` 的配置中声明了相应的 +`AppComponent` 和 `RouterLinkDirectiveStub`。 + But the compiler won't throw an error when it encounters ``, ``, or ``. It simply renders them as empty tags and the browser ignores them. +但编译器在遇到 ``、`` 或 `` 时不会报错。 +它只会把它们渲染成空白标签，而浏览器会忽略这些标签。 + You no longer need the stub components. +你不用再提供桩组件了。 + #### Use both techniques together +#### 同时使用这两项技术 + These are techniques for _Shallow Component Testing_ , so-named because they reduce the visual surface of the component to just those elements in the component's template that matter for tests. +这些是进行*浅层*测试要用到的技术，之所以叫浅层测试是因为只包含本测试所关心的这个组件模板中的元素。 + The `NO_ERRORS_SCHEMA` approach is the easier of the two but don't overuse it. +`NO_ERRORS_SCHEMA` 方法在这两者中比较简单，但也不要过度使用它。 + The `NO_ERRORS_SCHEMA` also prevents the compiler from telling you about the missing components and attributes that you omitted inadvertently or misspelled. You could waste hours chasing phantom bugs that the compiler would have caught in an instant. +`NO_ERRORS_SCHEMA` 还会阻止编译器告诉你因为的疏忽或拼写错误而缺失的组件和属性。 +你如果人工找出这些 bug 可能要浪费几个小时，但编译器可以立即捕获它们。 + The _stub component_ approach has another advantage. While the stubs in _this_ example were empty, you could give them stripped-down templates and classes if your tests need to interact with them in some way. +*桩组件*方式还有其它优点。 +虽然*这个*例子中的桩是空的，但你如果想要和它们用某种形式互动，也可以给它们一些裁剪过的模板和类。 + In practice you will combine the two techniques in the same setup, as seen in this example. +在实践中，你可以在设置代码中组合使用这两种技术，例子如下： + ` el and applies the `RouterLinkStubDirective` to the anchors with the `routerLink` attribute, but it ignores the `` and `` tags. +Angular 编译器会为 `` 元素创建 `BannerComponentStub`，并把 `RouterLinkStubDirective` 应用到带有 `routerLink` 属性的链接上，不过它会忽略 `` 和 `` 标签。 +
{@a routerlink}