测试
Testing
该指南提供了对 Angular 应用进行单元测试和集成测试的技巧和提示。
This guide offers tips and techniques for unit and integration testing Angular applications.
该指南中的测试针对的是一个很像《英雄指南》教程的 Angular CLI 范例应用。 这个范例应用及其所有测试都可以在下面的链接中进行查看和试用:
The guide presents tests of a sample application created with the Angular CLI. This sample application is much like the one created in the Tour of Heroes tutorial. The sample application and all tests in this guide are available for inspection and experimentation:
准备工作
Setup
Angular CLI 会下载并安装试用 Jasmine 测试框架 测试 Angular 应用时所需的一切。
The Angular CLI downloads and install everything you need to test an Angular application with the Jasmine test framework.
你使用 CLI 创建的项目是可以立即用于测试的。 运行 CLI 命令 ng test
即可:
The project you create with the CLI is immediately ready to test. Just run the ng test
CLI command:
ng test
ng test
命令在监视模式下构建应用,并启动 karma 测试运行器。
The ng test
command builds the app in watch mode, and launches the karma test runner.
它的控制台输出一般是这样的:
The console output looks a bit like this:
10% building modules 1/1 modules 0 active
...INFO [karma]: Karma v1.7.1 server started at http://0.0.0.0:9876/
...INFO [launcher]: Launching browser Chrome ...
...INFO [launcher]: Starting browser Chrome
...INFO [Chrome ...]: Connected on socket ...
Chrome ...: Executed 3 of 3 SUCCESS (0.135 secs / 0.205 secs)
最后一行很重要。它表示 Karma 运行了三个测试,而且这些测试都通过了。
The last line of the log is the most important. It shows that Karma ran three tests that all passed.
它还会打开 Chrome 浏览器并在“ Jasmine HTML 报告器”中显示测试输出,就像这样:
A chrome browser also opens and displays the test output in the "Jasmine HTML Reporter" like this.
![Jasmine HTML Reporter in the browser](generated/images/guide/testing/initial-jasmine-html-reporter.png)
大多数人都会觉得浏览器中的报告比控制台中的日志更容易阅读。 你可以点击一行测试,来单独重跑这个测试,或者点击一行描述信息来重跑所选测试组(“测试套件”)中的那些测试。
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").
同时,ng test
命令还会监听这些变化。
Meanwhile, the ng test
command is watching for changes.
要查看它的实际效果,就对 app.component.ts
做一个小修改,并保存它。 这些测试就会重新运行,浏览器也会刷新,然后新的测试结果就出现了。
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.
配置
Configuration
CLI 会为你生成 Jasmine 和 Karma 的配置文件。
The CLI takes care of Jasmine and karma configuration for you.
不过你也可以通过编辑 src/
目录下的 karma.conf.js
和 test.ts
文件来微调很多选项。
You can fine-tune many options by editing the karma.conf.js
and the test.ts
files in the src/
folder.
karma.conf.js
文件是 karma 配置文件的一部分。 CLI 会基于 angular.json
文件中指定的项目结构和 karma.conf.js
文件,来在内存中构建出完整的运行时配置。
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.json
file, supplemented by karma.conf.js
.
要进一步了解 Jasmine 和 Karma 的配置项,请搜索网络。
Search the web for more details about Jasmine and karma configuration.
其它测试框架
Other test frameworks
你还可以使用其它的测试库和测试运行器来对 Angular 应用进行单元测试。 每个库和运行器都有自己特有的安装过程、配置项和语法。
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.
要了解更多,请搜索网络。
Search the web to learn more.
测试文件名及其位置
Test file name and location
查看 src/app
文件夹。
Look inside the src/app
folder.
CLI 为 AppComponent
生成了一个名叫 app.component.spec.ts
的测试文件。
The CLI generated a test file for the AppComponent
named app.component.spec.ts
.
测试文件的扩展名必须是 .spec.ts
,这样工具才能识别出它是一个测试文件,也叫规约(spec)文件。
The test file extension must be .spec.ts
so that tooling can identify it as a file with tests (AKA, a spec file).
app.component.ts
和 app.component.spec.ts
文件位于同一个文件夹中,而且相邻。 其根文件名部分(app.component
)都是一样的。
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.
请在你的项目中对任意类型的测试文件都坚持这两条约定。
Adopt these two conventions in your own projects for every kind of test file.
建立持续集成环境
Set up continuous integration
避免项目出 BUG 的最佳方式之一,就是使用测试套件。但是很容易忘了一直运行它。 持续集成(CI)服务器让你可以配置项目的代码仓库,以便每次提交和收到 Pull Request 时就会运行你的测试。
One of the best ways to keep your project bug free is through a test suite, but it's easy to forget to run tests all the time. Continuous integration (CI) servers let you set up your project repository so that your tests run on every commit and pull request.
已经有一些像 Circle CI 和 Travis CI 这样的付费 CI 服务器,你还可以使用 Jenkins 或其它软件来搭建你自己的免费 CI 服务器。 虽然 Circle CI 和 Travis CI 是收费服务,但是它们也会为开源项目提供免费服务。 你可以在 GitHub 上创建公开项目,并免费享受这些服务。 当你为 Angular 仓库贡献代码时,就会自动用 Circle CI 和 Travis CI 运行整个测试套件。
There are paid CI services like Circle CI and Travis CI, and you can also host your own for free using Jenkins and others. Although Circle CI and Travis CI are paid services, they are provided free for open source projects. You can create a public project on GitHub and add these services without paying. Contributions to the Angular repo are automatically run through a whole suite of Circle CI and Travis CI tests.
本文档解释了如何配置你的项目,来运行 Circle CI 和 Travis CI,以及如何修改你的测试配置,以便能在这两个环境下用 Chrome 浏览器来运行测试。
This article explains how to configure your project to run Circle CI and Travis CI, and also update your test configuration to be able to run tests in the Chrome browser in either environment.
为 Circle CI 配置项目
Configure project for Circle CI
步骤一:在项目的根目录下创建一个名叫 .circleci
的目录。
Step 1: Create a folder called .circleci
at the project root.
步骤二:在这个新建的目录下,创建一个名为 config.yml
的文件,内容如下:
Step 2: In the new folder, create a file called config.yml
with the following content:
- version: 2
- jobs:
- build:
- working_directory: ~/my-project
- docker:
- - image: circleci/node:8-browsers
- steps:
- - checkout
- - restore_cache:
- key: my-project-{{ .Branch }}-{{ checksum "package-lock.json" }}
- - run: npm install
- - save_cache:
- key: my-project-{{ .Branch }}-{{ checksum "package-lock.json" }}
- paths:
- - "node_modules"
- - run: npm run test -- --no-watch --no-progress --browsers=ChromeHeadlessCI
- - run: npm run e2e -- --protractor-config=e2e/protractor-ci.conf.js
该配置会缓存 node_modules/
并使用 npm run
来运行 CLI 命令,因为 @angular/cli
并没有装到全局。 要把参数传给 npm
脚本,这个单独的双中线(--
)是必须的。
This configuration caches node_modules/
and uses npm run
to run CLI commands, because @angular/cli
is not installed globally. The double dash (--
) is needed to pass arguments into the npm
script.
步骤三:提交你的修改,并把它们推送到你的代码仓库中。
Step 3: Commit your changes and push them to your repository.
步骤四:注册 Circle CI,并添加你的项目。你的项目将会开始构建。
Step 4: Sign up for Circle CI and add your project. Your project should start building.
欲知详情,参见 Circle CI 文档。
Learn more about Circle CI from Circle CI documentation.
为 Travis CI 配置项目
Configure project for Travis CI
步骤一:在项目根目录下创建一个名叫 .travis.yml
的文件,内容如下:
Step 1: Create a file called .travis.yml
at the project root, with the following content:
- dist: trusty
- sudo: false
-
- language: node_js
- node_js:
- - "8"
-
- addons:
- apt:
- sources:
- - google-chrome
- packages:
- - google-chrome-stable
-
- cache:
- directories:
- - ./node_modules
-
- install:
- - npm install
-
- script:
- - npm run test -- --no-watch --no-progress --browsers=ChromeHeadlessCI
- - npm run e2e -- --protractor-config=e2e/protractor-ci.conf.js
它做的事情和 Circle CI 的配置文件一样,只是 Travis 不用 Chrome,而是用 Chromium 代替。
This does the same things as the Circle CI configuration, except that Travis doesn't come with Chrome, so we use Chromium instead.
步骤二:提交你的更改,并把它们推送到你的代码仓库。
Step 2: Commit your changes and push them to your repository.
步骤三:注册 Travis CI 并添加你的项目。 你需要推送一个新的提交,以触发构建。
Step 3: Sign up for Travis CI and add your project. You'll need to push a new commit to trigger a build.
欲知详情,参见 Travis CI 文档。
Learn more about Travis CI testing from Travis CI documentation.
为在 Chrome 中运行 CI 测试而配置 CLI
Configure CLI for CI testing in Chrome
当 CLI 命令 ng test
和 ng e2e
经常要在你的环境中运行 CI 测试时,你可能需要再调整一下配置,以运行 Chrome 浏览器测试。
When the CLI commands ng test
and ng e2e
are generally running the CI tests in your environment, you might still need to adjust your configuration to run the Chrome browser tests.
有一些文件是给 Karma(直译 "报应")测试运行器和 Protractor(直译 "量角器") 端到端测试运行器使用的,你必须改为不用沙箱的 Chrome 启动方式。
There are configuration files for both the Karma JavaScript test runner and Protractor end-to-end testing tool, which you must adjust to start Chrome without sandboxing.
这个例子中我们将使用无头 Chrome。
We'll be using Headless Chrome in these examples.
在 Karma 配置文件
karma.conf.js
中,浏览器的紧下方,添加自定义的启动器,名叫 ChromeNoSandbox。In the Karma configuration file,
karma.conf.js
, add a custom launcher called ChromeHeadlessCI below browsers:
browsers: ['Chrome'],
customLaunchers: {
ChromeHeadlessCI: {
base: 'ChromeHeadless',
flags: ['--no-sandbox']
}
},
在 e2e 测试项目的根目录下创建一个新文件
protractor-ci.conf.js
,它扩展了原始的protractor.conf.js
:In the root folder of your e2e tests project, create a new file named
protractor-ci.conf.js
. This new file extends the originalprotractor.conf.js
.
const config = require('./protractor.conf').config;
config.capabilities = {
browserName: 'chrome',
chromeOptions: {
args: ['--headless', '--no-sandbox']
}
};
exports.config = config;
现在你可以运行下列带有 --no-sandbox
标志的命令了:
Now you can run the following commands to use the --no-sandbox
flag:
ng test -- --no-watch --no-progress --browsers=ChromeHeadlessCI
ng e2e -- --protractor-config=e2e/protractor-ci.conf.js
注意:目前,如果你正运行在 Windows 中,还要包含 --disable-gpu
标志。参见 crbug.com/737678。
Note: Right now, you'll also want to include the --disable-gpu
flag if you're running on Windows. See crbug.com/737678.
启用代码覆盖率报告
Enable code coverage reports
CLI 可以运行单元测试,并创建代码覆盖率报告。 代码覆盖率报告会向你展示代码库中有哪些可能未使用单元测试正常测试过的代码。
The CLI can run unit tests and create code coverage reports. Code coverage reports show you any parts of our code base that may not be properly tested by your unit tests.
要生成覆盖率报告,请在项目的根目录下运行下列命令。
To generate a coverage report run the following command in the root of your project.
ng test --no-watch --code-coverage
当测试完成时,该命令会在项目中创建一个新的 /coverage
目录。打开其 index.html
文件以查看带有源码和代码覆盖率值的报告。
When the tests are complete, the command creates a new /coverage
folder in the project. Open the index.html
file to see a report with your source code and code coverage values.
如果你要在每次运行测试时都创建代码覆盖率报告,可以在 CLI 的配置文件 angular.json
中设置下列选项:
If you want to create code-coverage reports every time you test, you can set the following option in the CLI configuration file, angular.json
:
"test": {
"options": {
"codeCoverage": true
}
}
代码覆盖率实施
Code coverage enforcement
代码覆盖率能让你估计要测试的代码量。 如果你的开发组决定要设置单元测试的最小数量,就可以使用 Angular CLI 来守住这条底线。
The code coverage percentages let you estimate how much of your code is tested.
If your team decides on a set minimum amount to be unit tested, you can enforce this minimum with the Angular CLI.
比如,假设你希望代码有最少 80% 的代码覆盖率。 要启用它,请打开 Karma 测试平台的配置文件 karma.conf.js
,并添加键 coverageIstanbulReporter:
如下。
For example, suppose you want the code base to have a minimum of 80% code coverage. To enable this, open the Karma test platform configuration file, karma.conf.js
, and add the following in the coverageIstanbulReporter:
key.
coverageIstanbulReporter: {
reports: [ 'html', 'lcovonly' ],
fixWebpackSourcePaths: true,
thresholds: {
statements: 80,
lines: 80,
branches: 80,
functions: 80
}
}
这里的 thresholds
属性会让此工具在项目中运行单元测试时强制保证至少达到 80% 的测试覆盖率。
The thresholds
property causes the tool to enforce a minimum of 80% code coverage when the unit tests are run in the project.
对服务的测试
Service Tests
服务通常是单元测试中最简单的文件类型。 下面是一些针对 ValueService
的同步和异步单元测试, 编写它们时没有借助来自 Angular 测试工具集的任何协助。
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.
- // Straight Jasmine testing without Angular's testing support
- describe('ValueService', () => {
- let service: ValueService;
- beforeEach(() => { service = new ValueService(); });
-
- it('#getValue should return real value', () => {
- expect(service.getValue()).toBe('real value');
- });
-
- it('#getObservableValue should return value from observable',
- (done: DoneFn) => {
- service.getObservableValue().subscribe(value => {
- expect(value).toBe('observable value');
- done();
- });
- });
-
- it('#getPromiseValue should return value from a promise',
- (done: DoneFn) => {
- service.getPromiseValue().then(value => {
- expect(value).toBe('promise value');
- done();
- });
- });
- });
带有依赖的服务
Services with dependencies
服务通常会依赖于一些 Angular 注入到其构造函数中的其它服务。 多数情况下,创建并在调用该服务的构造函数时,手工创建并注入这些依赖也是很容易的。
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.
MasterService
就是一个简单的例子:
The MasterService
is a simple example:
@Injectable()
export class MasterService {
constructor(private valueService: ValueService) { }
getValue() { return this.valueService.getValue(); }
}
MasterService
把它唯一的方法 getValue
委托给了注入进来的 ValueService
。
MasterService
delegates its only method, getValue
, to the injected ValueService
.
这里是几种测试它的方法。
Here are several ways to test it.
- describe('MasterService without Angular testing support', () => {
- let masterService: MasterService;
-
- it('#getValue should return real value from the real service', () => {
- masterService = new MasterService(new ValueService());
- expect(masterService.getValue()).toBe('real value');
- });
-
- it('#getValue should return faked value from a fakeService', () => {
- masterService = new MasterService(new FakeValueService());
- expect(masterService.getValue()).toBe('faked service value');
- });
-
- it('#getValue should return faked value from a fake object', () => {
- const fake = { getValue: () => 'fake value' };
- masterService = new MasterService(fake as ValueService);
- expect(masterService.getValue()).toBe('fake value');
- });
-
- it('#getValue should return stubbed value from a spy', () => {
- // create `getValue` spy on an object representing the ValueService
- const valueServiceSpy =
- jasmine.createSpyObj('ValueService', ['getValue']);
-
- // set the value to return when the `getValue` spy is called.
- const stubValue = 'stub value';
- valueServiceSpy.getValue.and.returnValue(stubValue);
-
- masterService = new MasterService(valueServiceSpy);
-
- expect(masterService.getValue())
- .toBe(stubValue, 'service returned stub value');
- expect(valueServiceSpy.getValue.calls.count())
- .toBe(1, 'spy method was called once');
- expect(valueServiceSpy.getValue.calls.mostRecent().returnValue)
- .toBe(stubValue);
- });
- });
第一个测试使用 new
创建了 ValueService
,然后把它传给了 MasterService
的构造函数。
The first test creates a ValueService
with new
and passes it to the MasterService
constructor.
不过,对于大多数没这么容易创建和控制的依赖项来说,注入真实的服务很容易出问题。
However, injecting the real service rarely works well as most dependent services are difficult to create and control.
你可以改用模拟依赖的方式,你可以使用虚值或在相关的服务方法上创建一个间谍(spy)。
Instead you can mock the dependency, use a dummy value, or create a spy on the pertinent service method.
优先使用间谍,因为它们通常是 Mock 服务时最简单的方式。
Prefer spies as they are usually the easiest way to mock services.
这些标准的测试技巧对于在隔离的环境下对服务进行单元测试非常重要。
These standard testing techniques are great for unit testing services in isolation.
不过,你几乎迟早要用 Angular 的依赖注入机制来把服务注入到应用类中去,而且你应该已经有了这类测试。 Angular 的测试工具集可以让你轻松探查这种注入服务的工作方式。
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.
使用 TestBed
(测试机床)测试服务
Testing services with the TestBed
你的应用中会依赖 Angular 的依赖注入 (DI) 来创建服务。 当某个服务依赖另一个服务时,DI 就会找到或创建那个被依赖的服务。 如果那个被依赖的服务还有它自己的依赖,DI 也同样会找到或创建它们。
Your app relies on Angular dependency injection (DI) 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.
作为服务的消费方,你不需要关心这些细节。 你不用关心构造函数中的参数顺序或如何创建它们。
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.
但对于服务的测试方来说,你就至少要考虑服务的第一级依赖了。 不过你可以让 Angular DI 来负责服务的创建工作,但当你使用 TestBed
测试工具来提供和创建服务时,你仍然需要关心构造函数中的参数顺序。
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 TestBed
TestBed
是 Angular 测试工具中最重要的部分。 TestBed
会动态创建一个用来模拟 @NgModule 的 Angular 测试模块。
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.
TestBed.configureTestingModule()
方法接收一个元数据对象,其中具有 @NgModule 中的绝大多数属性。
The TestBed.configureTestingModule()
method takes a metadata object that can have most of the properties of an @NgModule.
要测试某个服务,就要在元数据的 providers
属性中指定一个将要进行测试或模拟的相关服务的数组。
To test a service, you set the providers
metadata property with an array of the services that you'll test or mock.
let service: ValueService;
beforeEach(() => {
TestBed.configureTestingModule({ providers: [ValueService] });
});
然后通过调用 TestBed.get()
(参数为该服务类)把它注入到一个测试中。
Then inject it inside a test by calling TestBed.get()
with the service class as the argument.
it('should use ValueService', () => {
service = TestBed.get(ValueService);
expect(service.getValue()).toBe('real value');
});
或者,如果你更倾向于把该服务作为环境准备过程的一部分,就把它放在 beforeEach()
中。
Or inside the beforeEach()
if you prefer to inject the service as part of your setup.
beforeEach(() => {
TestBed.configureTestingModule({ providers: [ValueService] });
service = TestBed.get(ValueService);
});
如果要测试一个带有依赖项的服务,那就把模拟对象放在 providers
数组中。
When testing a service with a dependency, provide the mock in the providers
array.
在下面的例子中,模拟对象是一个间谍(spy)对象。
In the following example, the mock is a spy object.
let masterService: MasterService;
let valueServiceSpy: jasmine.SpyObj<ValueService>;
beforeEach(() => {
const spy = jasmine.createSpyObj('ValueService', ['getValue']);
TestBed.configureTestingModule({
// Provide both the service-to-test and its (spy) dependency
providers: [
MasterService,
{ provide: ValueService, useValue: spy }
]
});
// Inject both the service-to-test and its (spy) dependency
masterService = TestBed.get(MasterService);
valueServiceSpy = TestBed.get(ValueService);
});
该测试会像以前一样消费这个间谍对象。
The test consumes that spy in the same way it did earlier.
it('#getValue should return stubbed value from a spy', () => {
const stubValue = 'stub value';
valueServiceSpy.getValue.and.returnValue(stubValue);
expect(masterService.getValue())
.toBe(stubValue, 'service returned stub value');
expect(valueServiceSpy.getValue.calls.count())
.toBe(1, 'spy method was called once');
expect(valueServiceSpy.getValue.calls.mostRecent().returnValue)
.toBe(stubValue);
});
不使用 beforeEach
进行测试
Testing without beforeEach()
本指南中的大多数的测试套件都会调用 beforeEach()
来为每个 it()
测试准备前置条件,并依赖 TestBed
来创建类和注入服务。
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()
,并且更倾向于显式创建类,而不要借助 TestBed
。
There's another school of testing that never calls beforeEach()
and prefers to create classes explicitly rather than use the TestBed
.
下面的例子教你如何把 MasterService
的测试改写成那种风格。
Here's how you might rewrite one of the MasterService
tests in that style.
通过把可复用的准备代码放进一个单独的 setup
函数来代替 beforeEach()
。
Begin by putting re-usable, preparatory code in a setup function instead of beforeEach()
.
function setup() {
const valueServiceSpy =
jasmine.createSpyObj('ValueService', ['getValue']);
const stubValue = 'stub value';
const masterService = new MasterService(valueServiceSpy);
valueServiceSpy.getValue.and.returnValue(stubValue);
return { masterService, stubValue, valueServiceSpy };
}
setup()
函数返回一个带有一些变量的对象字面量,比如 masterService
,测试中可以引用它。 这样你就不用在 describe()
中定义一些半全局性的变量了(比如 let masterService: MasterService
)。
The setup()
function returns an object literal with the variables, such as masterService
, that a test might reference. You don't define semi-global variables (e.g., let masterService: MasterService
) in the body of the describe()
.
然后,每个测试都会在第一行调用 setup()
,然后再操纵被测主体以及对期望值进行断言。
Then each test invokes setup()
in its first line, before continuing with steps that manipulate the test subject and assert expectations.
it('#getValue should return stubbed value from a spy', () => {
const { masterService, stubValue, valueServiceSpy } = setup();
expect(masterService.getValue())
.toBe(stubValue, 'service returned stub value');
expect(valueServiceSpy.getValue.calls.count())
.toBe(1, 'spy method was called once');
expect(valueServiceSpy.getValue.calls.mostRecent().returnValue)
.toBe(stubValue);
});
注意这些测试是如何使用 解构赋值 来提取出所需变量的。
Notice how the test uses destructuring assignment to extract the setup variables that it needs.
const { masterService, stubValue, valueServiceSpy } = setup();
很多开发者觉得这种方式相比传统的 beforeEach()
风格更加干净、更加明确。
Many developers feel this approach is cleaner and more explicit than the traditional beforeEach()
style.
虽然本章会遵循传统的风格,并且 CLI 生成的默认测试文件也用的是 beforeEach()
和 TestBed
,不过你可以在自己的项目中自由选择这种可选方式。
Although this testing guide follows the tradition style and the default CLI schematics generate test files with beforeEach()
and TestBed
, feel free to adopt this alternative approach in your own projects.
测试 HTTP 服务
Testing HTTP services
那些会向远端服务器发起 HTTP 调用的数据服务,通常会注入 Angular 的 HttpClient
服务并委托它进行 XHR 调用。
Data services that make HTTP calls to remote servers typically inject and delegate to the Angular HttpClient
service for XHR calls.
你可以像测试其它带依赖的服务那样,通过注入一个 HttpClient
间谍来测试这种数据服务。
You can test a data service with an injected HttpClient
spy as you would test any service with a dependency.
- let httpClientSpy: { get: jasmine.Spy };
- let heroService: HeroService;
-
- beforeEach(() => {
- // TODO: spy on other methods too
- httpClientSpy = jasmine.createSpyObj('HttpClient', ['get']);
- heroService = new HeroService(<any> httpClientSpy);
- });
-
- it('should return expected heroes (HttpClient called once)', () => {
- const expectedHeroes: Hero[] =
- [{ id: 1, name: 'A' }, { id: 2, name: 'B' }];
-
- httpClientSpy.get.and.returnValue(asyncData(expectedHeroes));
-
- heroService.getHeroes().subscribe(
- heroes => expect(heroes).toEqual(expectedHeroes, 'expected heroes'),
- fail
- );
- expect(httpClientSpy.get.calls.count()).toBe(1, 'one call');
- });
-
- it('should return an error when the server returns a 404', () => {
- const errorResponse = new HttpErrorResponse({
- error: 'test 404 error',
- status: 404, statusText: 'Not Found'
- });
-
- httpClientSpy.get.and.returnValue(asyncError(errorResponse));
-
- heroService.getHeroes().subscribe(
- heroes => fail('expected an error, not heroes'),
- error => expect(error.message).toContain('test 404 error')
- );
- });
HttpService
中的方法会返回 Observables
。订阅这些方法返回的可观察对象会让它开始执行,并且断言这些方法是成功了还是失败了。
The HeroService
methods return Observables
. You must subscribe to an observable to (a) cause it to execute and (b) assert that the method succeeds or fails.
subscribe()
方法接受一个成功回调 (next
) 和一个失败 (error
) 回调。 你要确保同时提供了这两个回调,以便捕获错误。 如果忽略这些异步调用中未捕获的错误,测试运行器可能会得出截然不同的测试结论。
The subscribe()
method takes a success (next
) and fail (error
) callback. Make sure you provide both callbacks so that you capture errors. Neglecting to do so produces an asynchronous uncaught observable error that the test runner will likely attribute to a completely different test.
HttpClientTestingModule
如果将来 HttpClient
和数据服务之间有更多的交互,则可能会变得复杂,而且难以使用间谍进行模拟。
Extended interactions between a data service and the HttpClient
can be complex and difficult to mock with spies.
HttpClientTestingModule
可以让这些测试场景变得更加可控。
The HttpClientTestingModule
can make these testing scenarios more manageable.
本章的代码范例要示范的是 HttpClientTestingModule
,所以把部分内容移到了 Http 一章,那里会详细讲解如何用 HttpClientTestingModule
进行测试。
While the code sample accompanying this guide demonstrates HttpClientTestingModule
, this page defers to the Http guide, which covers testing with the HttpClientTestingModule
in detail.
本章范例代码中的 app/model/http-hero.service.spec.ts
还示范了如何使用传统的 HttpModule
进行验证。
This guide's sample code also demonstrates testing of the legacy HttpModule
in app/model/http-hero.service.spec.ts
.
组件测试基础
Component Test Basics
组件与 Angular 应用中的其它部分不同,它是由 HTML 模板和 TypeScript 类组成的。 组件其实是指模板加上与其合作的类。 要想对组件进行充分的测试,就要测试它们能否如预期的那样协作。
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.
这些测试需要在浏览器的 DOM 中创建组件的宿主元素(就像 Angular 所做的那样),然后检查组件类和 DOM 的交互是否如同它在模板中所描述的那样。
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.
Angular 的 TestBed
为所有这些类型的测试提供了基础设施。 但是很多情况下,可以单独测试组件类本身而不必涉及 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.
单独测试组件类
Component class testing
你可以像测试服务类一样测试组件类。
Test a component class on its own as you would test a service class.
考虑下面这个 LightswitchComponent
,当用户点击按钮时,它会切换灯的开关状态(用屏幕上的消息展现出来)。
Consider this LightswitchComponent
which toggles a light on and off (represented by an on-screen message) when the user clicks the button.
@Component({
selector: 'lightswitch-comp',
template: `
<button (click)="clicked()">Click me!</button>
<span>{{message}}</span>`
})
export class LightswitchComponent {
isOn = false;
clicked() { this.isOn = !this.isOn; }
get message() { return `The light is ${this.isOn ? 'On' : 'Off'}`; }
}
你可能要测试 clicked()
方法能否正确切换灯的开关状态并设置合适的消息。
You might decide only to test that the clicked()
method toggles the light's on/off state and sets the message appropriately.
该组件类没有依赖。 要测试一个没有依赖的服务,你会用 new
来创建它,调用它的 API,然后对它的公开状态进行断言。 组件类也可以这么做。
This component class has no dependencies. To test a service with no dependencies, you create it with new
, poke at its API, and assert expectations on its public state. Do the same with the component class.
describe('LightswitchComp', () => {
it('#clicked() should toggle #isOn', () => {
const comp = new LightswitchComponent();
expect(comp.isOn).toBe(false, 'off at first');
comp.clicked();
expect(comp.isOn).toBe(true, 'on after click');
comp.clicked();
expect(comp.isOn).toBe(false, 'off after second click');
});
it('#clicked() should set #message to "is on"', () => {
const comp = new LightswitchComponent();
expect(comp.message).toMatch(/is off/i, 'off at first');
comp.clicked();
expect(comp.message).toMatch(/is on/i, 'on after clicked');
});
});
下面这段代码是来自《英雄指南》教程的 DashboardHeroComponent
。
Here is the DashboardHeroComponent
from the Tour of Heroes tutorial.
export class DashboardHeroComponent {
@Input() hero: Hero;
@Output() selected = new EventEmitter<Hero>();
click() { this.selected.emit(this.hero); }
}
它呈现在父组件的模板中,那里把一个英雄绑定到了 @Input
属性上,并且通过 @Output
属性监听选中英雄时的事件。
It appears within the template of a parent component, which binds a hero to the @Input
property and listens for an event raised through the selected @Output
property.
你可以测试 DashboardHeroComponent
类,而不用完整创建它或其父组件。
You can test that the class code works without creating the DashboardHeroComponent
or its parent component.
it('raises the selected event when clicked', () => {
const comp = new DashboardHeroComponent();
const hero: Hero = { id: 42, name: 'Test' };
comp.hero = hero;
comp.selected.subscribe(selectedHero => expect(selectedHero).toBe(hero));
comp.click();
});
当组件有依赖时,你可能要使用 TestBed
来同时创建该组件及其依赖。
When a component has dependencies, you may wish to use the TestBed
to both create the component and its dependencies.
下面的 WelcomeComponent
依赖于 UserService
,并通过它知道要打招呼的那位用户的名字。
The following WelcomeComponent
depends on the UserService
to know the name of the user to greet.
export class WelcomeComponent implements OnInit {
welcome: string;
constructor(private userService: UserService) { }
ngOnInit(): void {
this.welcome = this.userService.isLoggedIn ?
'Welcome, ' + this.userService.user.name : 'Please log in.';
}
}
你可能要先创建一个满足本组件最小需求的模拟板 UserService
。
You might start by creating a mock of the UserService
that meets the minimum needs of this component.
class MockUserService {
isLoggedIn = true;
user = { name: 'Test User'};
};
然后在 TestBed
的配置中提供并同时注入该组件和该服务。
Then provide and inject both the component and the service in the TestBed
configuration.
beforeEach(() => {
TestBed.configureTestingModule({
// provide the component-under-test and dependent service
providers: [
WelcomeComponent,
{ provide: UserService, useClass: MockUserService }
]
});
// inject both the component and the dependent service.
comp = TestBed.get(WelcomeComponent);
userService = TestBed.get(UserService);
});
然后使用这个组件类,别忘了像 Angular 运行本应用时那样调用它的生命周期钩子方法。
Then exercise the component class, remembering to call the lifecycle hook methods as Angular does when running the app.
it('should not have welcome message after construction', () => {
expect(comp.welcome).toBeUndefined();
});
it('should welcome logged in user after Angular calls ngOnInit', () => {
comp.ngOnInit();
expect(comp.welcome).toContain(userService.user.name);
});
it('should ask user to log in if not logged in after ngOnInit', () => {
userService.isLoggedIn = false;
comp.ngOnInit();
expect(comp.welcome).not.toContain(userService.user.name);
expect(comp.welcome).toContain('log in');
});
组件 DOM 的测试
Component DOM testing
测试组件类就像测试服务那样简单。
Testing the component class is as easy as testing a service.
但组件不仅是这个类。 组件还要和 DOM 以及其它组件进行交互。 只涉及类的测试可以告诉你组件类的行为是否正常, 但是不能告诉你组件是否能正常渲染出来、响应用户的输入和查询或与它的父组件和子组件相集成。
But a component is more than just its class. A component interacts with the DOM and with other components. The class-only tests can tell you about class behavior. They cannot tell you if the component is going to render properly, respond to user input and gestures, or integrate with its parent and child components.
上述只涉及类的测试没办法回答这些组件在屏幕上的行为之类的关键性问题:
None of the class-only tests above can answer key questions about how the components actually behave on screen.
Lightswitch.clicked()
是否真的绑定到了某些用户可以接触到的东西?Is
Lightswitch.clicked()
bound to anything such that the user can invoke it?Lightswitch.message
是否真的显示出来了?Is the
Lightswitch.message
displayed?用户真的可以选择
DashboardHeroComponent
中显示的某个英雄吗?Can the user actually select the hero displayed by
DashboardHeroComponent
?英雄的名字是否如预期般显示出来了?(比如是否大写)
Is the hero name displayed as expected (i.e, in uppercase)?
WelcomeComponent
的模板是否显示了欢迎信息?Is the welcome message displayed by the template of
WelcomeComponent
?
这些问题对于上面这种简单的组件来说当然没有问题, 不过很多组件和它们模板中所描述的 DOM 元素之间会有复杂的交互,当组件的状态发生变化时,会导致一些 HTML 出现和消失。
These may not be troubling questions for the simple components illustrated above. But many components have complex interactions with the DOM elements described in their templates, causing HTML to appear and disappear as the component state changes.
要回答这类问题,你就不得不创建那些与组件相关的 DOM 元素了,你必须检查 DOM 来确认组件的状态能在恰当的时机正常显示出来,并且必须通过屏幕来仿真用户的交互,以判断这些交互是否如预期的那般工作。
To answer these kinds of questions, you have to create the DOM elements associated with the components, you must examine the DOM to confirm that component state displays properly at the appropriate times, and you must simulate user interaction with the screen to determine whether those interactions cause the component to behave as expected.
要想写这类测试,你就要用到 TestBed
的附加功能以及其它测试助手了。
To write these kinds of test, you'll use additional features of the TestBed
as well as other testing helpers.
CLI 生成的测试
CLI-generated tests
当你用 CLI 生成新的组件时,它也会默认创建最初的测试文件。
The CLI creates an initial test file for you by default when you ask it to generate a new component.
比如,下列 CLI 命令会在 app/banner
文件夹中生成带有内联模板和内联样式的 BannerComponent
:
For example, the following CLI command generates a BannerComponent
in the app/banner
folder (with inline template and styles):
ng generate component banner --inline-template --inline-style --module app
它也会为组件生成最初的测试文件 banner-external.component.spec.ts
,代码如下:
It also generates an initial test file for the component, banner-external.component.spec.ts
, that looks like this:
import { async, ComponentFixture, TestBed } from '@angular/core/testing';
import { BannerComponent } from './banner.component';
describe('BannerComponent', () => {
let component: BannerComponent;
let fixture: ComponentFixture<BannerComponent>;
beforeEach(async(() => {
TestBed.configureTestingModule({
declarations: [ BannerComponent ]
})
.compileComponents();
}));
beforeEach(() => {
fixture = TestBed.createComponent(BannerComponent);
component = fixture.componentInstance;
fixture.detectChanges();
});
it('should create', () => {
expect(component).toBeDefined();
});
});
缩减环境准备代码
Reduce the setup
这个文件中只有最后三行是真正测试组件的,它们用来断言 Angular 可以创建该组件。
Only the last three lines of this file actually test the component and all they do is assert that Angular can create the component.
文件的其它部分都是为更高级的测试二准备的样板代码,当组件逐渐演变成更加实质性的东西时,它们才可能变成必备的。
The rest of the file is boilerplate setup code anticipating more advanced tests that might become necessary if the component evolves into something substantial.
稍后你将学到这些高级的测试特性。 不过目前,你可以先把这些测试文件缩减成更加可控的大小,以便理解:
You'll learn about these advanced test features below. For now, you can radically reduce this test file to a more manageable size:
describe('BannerComponent (minimal)', () => {
it('should create', () => {
TestBed.configureTestingModule({
declarations: [ BannerComponent ]
});
const fixture = TestBed.createComponent(BannerComponent);
const component = fixture.componentInstance;
expect(component).toBeDefined();
});
});
在这个例子中,传给 TestBed.configureTestingModule
的元数据对象中只声明了 BannerComponent
—— 待测试的组件。
In this example, the metadata object passed to TestBed.configureTestingModule
simply declares BannerComponent
, the component to test.
TestBed.configureTestingModule({
declarations: [ BannerComponent ]
});
不用声明或导入任何其它的东西。 默认的测试模块中已经预先配置好了一些东西,比如来自 @angular/platform-browser
的 BrowserModule
。
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
.
稍后你将会调用带有导入模块、服务提供商和更多可声明对象的 TestBed.configureTestingModule()
来满足测试所需。 将来还可以用可选的 override
方法对这些配置进行微调。
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.
createComponent()
在配置好 TestBed
之后,你还可以调用它的 createComponent()
方法。
After configuring TestBed
, you call its createComponent()
method.
const fixture = TestBed.createComponent(BannerComponent);
TestBed.createComponent()
会创建一个 BannerComponent
的实例,把相应的元素添加到测试运行器的 DOM 中,然后返回一个 ComponentFixture
对象。
TestBed.createComponent()
creates an instance of the BannerComponent
, adds a corresponding element to the test-runner DOM, and returns a ComponentFixture
.
在调用了 createComponent
之后就不能再重新配置 TestBed
了。
Do not re-configure TestBed
after calling createComponent
.
createComponent
方法冻结了当前的 TestBed
定义,关闭它才能再进行后续配置。
The createComponent
method freezes the current TestBed
definition, closing it to further configuration.
你不能再调用任何 TestBed
的后续配置方法了,不能调 configureTestingModule()
、不能调 get()
, 也不能调用任何 override...
方法。 如果试图这么做,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.
ComponentFixture
ComponentFixture 是一个测试挽具(就像马车缰绳),用来与所创建的组件及其 DOM 元素进行交互。
The ComponentFixture is a test harness for interacting with the created component and its corresponding element.
可以通过测试夹具(fixture)来访问该组件的实例,并用 Jasmine 的 expect
语句来确保其存在。
Access the component instance through the fixture and confirm it exists with a Jasmine expectation:
const component = fixture.componentInstance;
expect(component).toBeDefined();
beforeEach()
随着该组件的成长,你将会添加更多测试。 除了为每个测试都复制一份 TestBed
测试之外,你还可以把它们重构成 Jasmine 的 beforeEach()
中的准备语句以及一些支持性变量:
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:
describe('BannerComponent (with beforeEach)', () => {
let component: BannerComponent;
let fixture: ComponentFixture<BannerComponent>;
beforeEach(() => {
TestBed.configureTestingModule({
declarations: [ BannerComponent ]
});
fixture = TestBed.createComponent(BannerComponent);
component = fixture.componentInstance;
});
it('should create', () => {
expect(component).toBeDefined();
});
});
现在,添加一个测试,用它从 fixture.nativeElement
中获取组件的元素,并查找是否存在所预期的文本内容。
Now add a test that gets the component's element from fixture.nativeElement
and looks for the expected text.
it('should contain "banner works!"', () => {
const bannerElement: HTMLElement = fixture.nativeElement;
expect(bannerElement.textContent).toContain('banner works!');
});
nativeElement
ComponentFixture.nativeElement
的值是 any
类型的。 稍后你将遇到的 DebugElement.nativeElement
也同样是 any
类型的。
The value of ComponentFixture.nativeElement
has the any
type. Later you'll encounter the DebugElement.nativeElement
and it too has the any
type.
Angular 在编译期间没办法知道 nativeElement
是哪种 HTML 元素,甚至是否 HTML 元素(译注:比如可能是 SVG 元素)。 本应用还可能运行在非浏览器平台上,比如服务端渲染或 Web Worker 那里的元素可能只有一些缩水过的 API,甚至根本不存在。
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, where the element may have a diminished API or not exist at all.
本指南中的测试都是为运行在浏览器中而设计的,因此 nativeElement
的值一定会是 HTMLElement
或其派生类。
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.
如果知道了它是某种 HTMLElement
,你就可以用标准的 querySelector
在元素树中进行深挖了。
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
来获取 <p>
元素,并在其中查找 Banner 文本:
Here's another test that calls HTMLElement.querySelector
to get the paragraph element and look for the banner text:
it('should have <p> with "banner works!"', () => {
const bannerElement: HTMLElement = fixture.nativeElement;
const p = bannerElement.querySelector('p');
expect(p.textContent).toEqual('banner works!');
});
DebugElement
Angular 的夹具可以通过 fixture.nativeElement
直接提供组件的元素。
The Angular fixture provides the component's element directly through the fixture.nativeElement
.
const bannerElement: HTMLElement = fixture.nativeElement;
它实际上是 fixture.debugElement.nativeElement
的一个便利方法。
This is actually a convenience method, implemented as fixture.debugElement.nativeElement
.
const bannerDe: DebugElement = fixture.debugElement;
const bannerEl: HTMLElement = bannerDe.nativeElement;
这种访问元素的迂回方式有很好的理由。
There's a good reason for this circuitous path to the element.
nativeElement
的属性取决于运行环境。 你可以在没有 DOM,或者其 DOM 模拟器无法支持全部 HTMLElement
API 的平台上运行这些测试。
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.
Angular 依赖于 DebugElement
这个抽象层,就可以安全的横跨其支持的所有平台。 Angular 不再创建 HTML 元素树,而是创建 DebugElement
树,其中包裹着相应运行平台上的原生元素。 nativeElement
属性会解开 DebugElement
,并返回平台相关的元素对象。
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.
因为本章的这些测试都设计为只运行在浏览器中,因此这些测试中的 nativeElement
总是 HTMLElement
, 你可以在测试中使用那些熟悉的方法和属性进行浏览。
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.
下面是对上一个测试改用 fixture.debugElement.nativeElement
进行的重新实现:
Here's the previous test, re-implemented with fixture.debugElement.nativeElement
:
it('should find the <p> with fixture.debugElement.nativeElement)', () => {
const bannerDe: DebugElement = fixture.debugElement;
const bannerEl: HTMLElement = bannerDe.nativeElement;
const p = bannerEl.querySelector('p');
expect(p.textContent).toEqual('banner works!');
});
DebugElement
还有其它的方法和属性,它们在测试中也很有用,你将在本章的其它测试中看到它们。
The DebugElement
has other methods and properties that are useful in tests, as you'll see elsewhere in this guide.
你要从 Angular 核心库中导入 DebugElement
符号。
You import the DebugElement
symbol from the Angular core library.
import { DebugElement } from '@angular/core';
By.css()
虽然本章中的测试都是运行在浏览器中的,不过有些应用可能会运行在其它平台上(至少一部分时间是这样)。
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.
比如,作为加快慢速网络设备上应用启动速度的一种策略,组件可能要先在服务器上渲染。服务端渲染可能无法支持完全的 HTML API。 如果它不支持 querySelector
,那么前一个测试就会失败。
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.
DebugElement
提供了可以工作在所有受支持的平台上的查询方法。 这些查询方法接受一个谓词(predicate)函数,如果 DebugElement
树中的节点满足某个筛选条件,它就返回 true
。
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.
你可以在从库中导入的 By
类的帮助下为该运行平台创建谓词函数。下面这个 By
是从浏览器平台导入的:
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:
import { By } from '@angular/platform-browser';
下面这个例子使用 DebugElement.query()
和浏览器的 By.css
方法重新实现了前一个测试。
The following example re-implements the previous test with DebugElement.query()
and the browser's By.css
method.
it('should find the <p> with fixture.debugElement.query(By.css)', () => {
const bannerDe: DebugElement = fixture.debugElement;
const paragraphDe = bannerDe.query(By.css('p'));
const p: HTMLElement = paragraphDe.nativeElement;
expect(p.textContent).toEqual('banner works!');
});
值得注意的地方有:
Some noteworthy observations:
By.css()
静态方法使用标准 CSS 选择器选择了一些DebugElement
节点。The
By.css()
static method selectsDebugElement
nodes with a standard CSS selector.这次查询返回了
<p>
元素的一个DebugElement
。The query returns a
DebugElement
for the paragraph.你必须解包此结果,以获取这个
<p>
元素。You must unwrap that result to get the paragraph element.
当你要通过 CSS 选择器过滤,并且只打算测试浏览器的原生元素的属性时,By.css
这种方法就有点多余了。
When you're filtering by CSS selector and only testing properties of a browser's native element, the By.css
approach may be overkill.
使用标准的 HTMLElement
方法,比如 querySelector()
或 querySelectorAll()
通常会更简单、更清晰。 你在下一组测试中就会体会到这一点。
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.
组件测试场景
Component Test Scenarios
下面这些部分构成了本指南的大部分内容,它们将探讨一些常见的组件测试场景。
The following sections, comprising most of this guide, explore common component testing scenarios
组件绑定
Component binding
当前的 BannerComponent
在 HTML 模板中展示了静态标题内容。
The current BannerComponent
presents static title text in the HTML template.
稍作修改之后,BannerComponent
也可以通过绑定到组件的 title
属性来展示动态标题。就像这样:
After a few changes, the BannerComponent
presents a dynamic title by binding to the component's title
property like this.
@Component({
selector: 'app-banner',
template: '<h1>{{title}}</h1>',
styles: ['h1 { color: green; font-size: 350%}']
})
export class BannerComponent {
title = 'Test Tour of Heroes';
}
很简单,你决定添加一个测试来确定这个组件真的像你预期的那样显示出了正确的内容。
Simple as this is, you decide to add a test to confirm that component actually displays the right content where you think it should.
查询 <h1>
Query for the <h1>
你将会写一系列测试来探查 <h1>
元素的值,这个值包含在了带有 title
属性的插值表达式绑定中。
You'll write a sequence of tests that inspect the value of the <h1>
element that wraps the title property interpolation binding.
你要修改 beforeEach
来使用标准的 HTML querySelector
来找到该元素,并把它赋值给 h1
变量。
You update the beforeEach
to find that element with a standard HTML querySelector
and assign it to the h1
variable.
let component: BannerComponent;
let fixture: ComponentFixture<BannerComponent>;
let h1: HTMLElement;
beforeEach(() => {
TestBed.configureTestingModule({
declarations: [ BannerComponent ],
});
fixture = TestBed.createComponent(BannerComponent);
component = fixture.componentInstance; // BannerComponent test instance
h1 = fixture.nativeElement.querySelector('h1');
});
createComponent()
函数不会绑定数据
createComponent() does not bind data
你的第一个测试希望看到屏幕显示出了默认的 title
。 你本能的写出如下测试来立即审查这个 <h1>
元素:
For your first test you'd like to see that the screen displays the default title
. Your instinct is to write a test that immediately inspects the <h1>
like this:
it('should display original title', () => {
expect(h1.textContent).toContain(component.title);
});
但测试失败了,给出如下信息:
That test fails with the message:
expected '' to contain 'Test Tour of Heroes'.
因为绑定是在 Angular 执行变更检测时才发生的。
Binding happens when Angular performs change detection.
在产品阶段,当 Angular 创建组件、用户输入或者异步动作(比如 AJAX)完成时,会自动触发变更检测。
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.
但 TestBed.createComponent
不能触发变更检测。 可以在这个修改后的测试中确定这一点:
The TestBed.createComponent
does not trigger change detection. a fact confirmed in the revised test:
it('no title in the DOM after createComponent()', () => {
expect(h1.textContent).toEqual('');
});
detectChanges()
你必须通过调用 fixture.detectChanges()
来要求 TestBed
执行数据绑定。 然后 <h1>
中才会具有所期望的标题。
You must tell the TestBed
to perform data binding by calling fixture.detectChanges()
. Only then does the <h1>
have the expected title.
it('should display original title after detectChanges()', () => {
fixture.detectChanges();
expect(h1.textContent).toContain(component.title);
});
这种迟到的变更检测是故意设计的,而且很有用。 它给了测试者一个机会,在 Angular 初始化数据绑定以及调用生命周期钩子之前探查并改变组件的状态。
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.
下面这个测试中,会在调用 fixture.detectChanges()
之前修改组件的 title
属性。
Here's another test that changes the component's title
property before calling fixture.detectChanges()
.
it('should display a different test title', () => {
component.title = 'Test Title';
fixture.detectChanges();
expect(h1.textContent).toContain('Test Title');
});
自动变更检测
Automatic change detection
BannerComponent
的这些测试需要频繁调用 detectChanges
。 有些测试者更喜欢让 Angular 测试环境自动运行变更检测。
The BannerComponent
tests frequently call detectChanges
. Some testers prefer that the Angular test environment run change detection automatically.
使用 ComponentFixtureAutoDetect
服务提供商来配置 TestBed
就可以做到这一点。 首先从测试工具库中导入它:
That's possible by configuring the TestBed
with the ComponentFixtureAutoDetect
provider. First import it from the testing utility library:
import { ComponentFixtureAutoDetect } from '@angular/core/testing';
然后把它添加到测试模块配置的 providers
数组中:
Then add it to the providers
array of the testing module configuration:
TestBed.configureTestingModule({
declarations: [ BannerComponent ],
providers: [
{ provide: ComponentFixtureAutoDetect, useValue: true }
]
});
这三个测试阐明了自动变更检测的工作原理。
Here are three tests that illustrate how automatic change detection works.
it('should display original title', () => {
// Hooray! No `fixture.detectChanges()` needed
expect(h1.textContent).toContain(comp.title);
});
it('should still see original title after comp.title change', () => {
const oldTitle = comp.title;
comp.title = 'Test Title';
// Displayed title is old because Angular didn't hear the change :(
expect(h1.textContent).toContain(oldTitle);
});
it('should display updated title after detectChanges', () => {
comp.title = 'Test Title';
fixture.detectChanges(); // detect changes explicitly
expect(h1.textContent).toContain(comp.title);
});
第一个测试程序展示了自动检测的好处。
The first test shows the benefit of automatic change detection.
第二和第三个测试程序显示了它重要的局限性。 Angular 测试环境不会知道测试程序改变了组件的 title
属性。 自动检测只对异步行为比如承诺的解析、计时器和 DOM 事件作出反应。 但是直接修改组件属性值的这种同步更新是不会触发自动检测的。 测试程序必须手动调用 fixture.detectChange()
,来触发新一轮的变更检测周期。
The second and third test reveal an important limitation. The Angular testing environment does not know that the test changed the component's title
. The ComponentFixtureAutoDetect
service responds to asynchronous activities such as promise resolution, timers, and DOM events. 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.
相比于受测试工具有没有执行变更检测的困扰,本章中的例子更愿意总是显式调用 detectChanges()
。 即使是在不需要的时候,频繁调用 detectChanges()
也没有任何坏处。
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.
使用 dispatchEvent()
修改输入值
Change an input value with dispatchEvent()
要想模拟用户输入,你就要找到 <input>
元素并设置它的 value
属性。
To simulate user input, you can find the input element and set its value
property.
你要调用 fixture.detectChanges()
来触发 Angular 的变更检测。 但那只是一个基本的中间步骤。
You will call fixture.detectChanges()
to trigger Angular's change detection. But there is an essential, intermediate step.
Angular 不知道你设置了这个 <input>
元素的 value
属性。 在你通过调用 dispatchEvent()
触发了该输入框的 input
事件之前,它不能读到那个值。 调用完之后你再调用 detectChanges()
。
Angular doesn't know that you set the input element's value
property. It won't read that property until you raise the element's input
event by calling dispatchEvent()
. Then you call detectChanges()
.
下面的例子演示了这个调用顺序。
The following example demonstrates the proper sequence.
- it('should convert hero name to Title Case', () => {
- // get the name's input and display elements from the DOM
- const hostElement = fixture.nativeElement;
- const nameInput: HTMLInputElement = hostElement.querySelector('input');
- const nameDisplay: HTMLElement = hostElement.querySelector('span');
-
- // simulate user entering a new name into the input box
- nameInput.value = 'quick BROWN fOx';
-
- // dispatch a DOM event so that Angular learns of input value change.
- nameInput.dispatchEvent(newEvent('input'));
-
- // Tell Angular to update the display binding through the title pipe
- fixture.detectChanges();
-
- expect(nameDisplay.textContent).toBe('Quick Brown Fox');
- });
带有外部文件的组件
Component with external files
上面的 BannerComponent
定义了一个内联模板和内联 CSS,分别是在 @Component.template
和 @Component.styles
属性中指定的。
The BannerComponent
above is defined with an inline template and inline css, specified in the @Component.template
and @Component.styles
properties respectively.
很多组件会分别用 @Component.templateUrl
和 @Component.styleUrls
属性来指定外部模板和外部 CSS,就像下面这个 BannerComponent
的变体中所做的一样:
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({
selector: 'app-banner',
templateUrl: './banner-external.component.html',
styleUrls: ['./banner-external.component.css']
})
这个语法告诉 Angular 编译器在编译期间读取外部文件。
This syntax tells the Angular compiler to read the external files during component compilation.
当你运行 CLI 的 ng test
命令的时候这毫无问题,因为它会在运行测试之前先编译该应用。
That's not a problem when you run the CLI ng test
command because it compiles the app before running the tests.
不过,如果你在非 CLI 环境下运行这些测试,那么对该组件的测试就可能失败。 比如,如果你在像 plunker 这样的 Web 编程环境下运行 BannerComponent
的测试,就会看到如下信息:
However, if you run the tests in a non-CLI environment, tests of this component may fail. For example, if you run the BannerComponent
tests in a web coding environment such as plunker, you'll see a message like this one:
Error: This test module uses the component BannerComponent
which is using a "templateUrl" or "styleUrls", but they were never compiled.
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.
要解决这个问题,可以像稍后解释的那样调用一次 compileComponents()
。
To correct the problem, call compileComponents()
as explained below.
带依赖的组件
Component with a dependency
组件经常依赖其他服务。
Components often have service dependencies.
WelcomeComponent
为登陆的用户显示一条欢迎信息。它从注入的 UserService
的属性得知用户的身份:
The WelcomeComponent
displays a welcome message to the logged in user. It knows who the user is based on a property of the injected UserService
:
import { Component, OnInit } from '@angular/core';
import { UserService } from '../model/user.service';
@Component({
selector: 'app-welcome',
template: '<h3 class="welcome"><i>{{welcome}}</i></h3>'
})
export class WelcomeComponent implements OnInit {
welcome: string;
constructor(private userService: UserService) { }
ngOnInit(): void {
this.welcome = this.userService.isLoggedIn ?
'Welcome, ' + this.userService.user.name : 'Please log in.';
}
}
WelcomeComponent
带有与服务交互的决策逻辑,这些逻辑让该组件值得测试。 下面是 app/welcome/welcome.component.spec.ts
中的测试模块配置:
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
:
TestBed.configureTestingModule({
declarations: [ WelcomeComponent ],
// providers: [ UserService ] // NO! Don't provide the real service!
// Provide a test-double instead
providers: [ {provide: UserService, useValue: userServiceStub } ]
});
这次,在测试配置里不但声明了被测试的组件,而且在 providers
数组中添加了 UserService
依赖。但不是真实的 UserService
。
This time, in addition to declaring the component-under-test, the configuration adds a UserService
provider to the providers
list. But not the real UserService
.
提供服务的测试替身
Provide service test doubles
被测试的组件不一定要注入真正的服务。实际上,服务的替身(Stub - 桩, Fake - 假冒品, Spy - 间谍或者 Mock - 模拟对象)通常会更加合适。 spec 的主要目的是测试组件,而不是服务。真实的服务可能连自身都有问题,不应该让它干扰对组件的测试。
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.
注入真实的 UserService
有可能很麻烦。真实的服务可能询问用户登录凭据,也可能试图连接认证服务器。 可能很难处理这些行为。所以在真实的 UserService
的位置创建和注册 UserService
替身,会让测试更加容易和安全。
Injecting the real UserService
could be a nightmare. The real service might ask the user for login credentials and attempt to reach an authentication server. These behaviors can be hard to intercept. It is far easier and safer to create and register a test double in place of the real UserService
.
这个测试套件提供了 UserService
的一个最小化模拟对象,它能满足 WelcomeComponent
及其测试的需求:
This particular test suite supplies a minimal mock of the UserService
that satisfies the needs of the WelcomeComponent
and its tests:
let userServiceStub: Partial<UserService>;
userServiceStub = {
isLoggedIn: true,
user: { name: 'Test User'}
};
获取注入的服务
Get injected services
测试程序需要访问被注入到 WelcomeComponent
中的 UserService
(stub 类)。
The tests need access to the (stub) UserService
injected into the WelcomeComponent
.
Angular 的注入系统是层次化的。 可以有很多层注入器,从根 TestBed
创建的注入器下来贯穿整个组件树。
Angular has a hierarchical injection system. There can be injectors at multiple levels, from the root injector created by the TestBed
down through the component tree.
最安全并总是有效的获取注入服务的方法,是从被测组件的注入器获取。 组件注入器是 fixture 的 DebugElement
的属性之一。
The safest way to get the injected service, the way that always works, is to get it from the injector of the component-under-test. The component injector is a property of the fixture's DebugElement
.
// UserService actually injected into the component
userService = fixture.debugElement.injector.get(UserService);
TestBed.get()
你也可能通过 TestBed.get()
来使用根注入器获取该服务。 这样更容易记住而且不那么啰嗦。 不过这只有当 Angular 组件需要的恰好是该测试的根注入器时才能正常工作。
You may also be able to get the service from the root injector via TestBed.get()
. This is easier to remember and less verbose. But it only works when Angular injects the component with the service instance in the test's root injector.
在这个测试套件中,UserService
唯一的提供商就是根测试模块中的,因此调用 TestBed.get()
就是安全的,代码如下:
In this test suite, the only provider of UserService
is the root testing module, so it is safe to call TestBed.get()
as follows:
// UserService from the root injector
userService = TestBed.get(UserService);
对于那些不能用 TestBed.get()
的测试用例,请参见改写组件的提供商一节,那里解释了何时以及为何必须改从组件自身的注入器中获取服务。
For a use case in which TestBed.get()
does not work, see the Override component providers section that explains when and why you must get the service from the component's injector instead.
总是从注入其中获取服务
Always get the service from an injector
请不要引用测试代码里提供给测试模块的 userServiceStub
对象。这样不行! 被注入组件的 userService
实例是完全不一样的对象,它提供的是 userServiceStub
的克隆。
Do not reference the userServiceStub
object that's provided to the testing module in the body of your test. It does not work! The userService
instance injected into the component is a completely different object, a clone of the provided userServiceStub
.
it('stub object and injected UserService should not be the same', () => {
expect(userServiceStub === userService).toBe(false);
// Changing the stub object has no effect on the injected service
userServiceStub.isLoggedIn = false;
expect(userService.isLoggedIn).toBe(true);
});
最终的准备及测试代码
Final setup and tests
下面是使用 TestBed.get()
的完整的 beforeEach()
:
Here's the complete beforeEach()
, using TestBed.get()
:
let userServiceStub: Partial<UserService>;
beforeEach(() => {
// stub UserService for test purposes
userServiceStub = {
isLoggedIn: true,
user: { name: 'Test User'}
};
TestBed.configureTestingModule({
declarations: [ WelcomeComponent ],
providers: [ {provide: UserService, useValue: userServiceStub } ]
});
fixture = TestBed.createComponent(WelcomeComponent);
comp = fixture.componentInstance;
// UserService from the root injector
userService = TestBed.get(UserService);
// get the "welcome" element by CSS selector (e.g., by class name)
el = fixture.nativeElement.querySelector('.welcome');
});
下面是一些测试程序:
And here are some tests:
it('should welcome the user', () => {
fixture.detectChanges();
const content = el.textContent;
expect(content).toContain('Welcome', '"Welcome ..."');
expect(content).toContain('Test User', 'expected name');
});
it('should welcome "Bubba"', () => {
userService.user.name = 'Bubba'; // welcome message hasn't been shown yet
fixture.detectChanges();
expect(el.textContent).toContain('Bubba');
});
it('should request login if not logged in', () => {
userService.isLoggedIn = false; // welcome message hasn't been shown yet
fixture.detectChanges();
const content = el.textContent;
expect(content).not.toContain('Welcome', 'not welcomed');
expect(content).toMatch(/log in/i, '"log in"');
});
第一个测试程序是合法测试程序,它确认这个被模拟的 UserService
是否被调用和工作正常。
The first is a sanity test; it confirms that the stubbed UserService
is called and working.
Jasmine 匹配器的第二个参数(比如 'expected name'
)是一个可选的失败标签。 如果这个期待语句失败了,Jasmine 就会把这个标签追加到这条个期待语句的失败信息后面。 对于具有多个期待语句的规约,它可以帮助澄清到底什么出错了,以及哪个期待语句失败了。
The second parameter to the Jasmine matcher (e.g., 'expected name'
) is an optional failure label. 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.
接下来的测试程序确认当服务返回不同的值时组件的逻辑是否工作正常。 第二个测试程序验证变换用户名字的效果。 第三个测试程序检查如果用户没有登录,组件是否显示正确消息。
The remaining tests confirm the logic of the component when the service returns different values. The second test validates the effect of changing the user name. The third test checks that the component displays the proper message when there is no logged-in user.
带有异步服务的组件
Component with async service
在这个例子中,AboutComponent
的模板中还有一个 TwainComponent
。 TwainComponent
用于显示引自马克·吐温的话。
In this sample, the AboutComponent
template hosts a TwainComponent
. The TwainComponent
displays Mark Twain quotes.
template: `
<p class="twain"><i>{{quote | async}}</i></p>
<button (click)="getQuote()">Next quote</button>
<p class="error" *ngIf="errorMessage">{{ errorMessage }}</p>`,
注意该组件的 quote
属性的值是通过 AsyncPipe
传进来的。 这意味着该属性或者返回 Promise
或者返回 Observable
。
Note that value of the component's quote
property passes through an AsyncPipe
. That means the property returns either a Promise
or an Observable
.
在这个例子中,TwainComponent.getQuote()
方法告诉你 quote
方法返回的是 Observable
。
In this example, the TwainComponent.getQuote()
method tells you that the quote
property returns an Observable
.
getQuote() {
this.errorMessage = '';
this.quote = this.twainService.getQuote().pipe(
startWith('...'),
catchError( (err: any) => {
// Wait a turn because errorMessage already set once this turn
setTimeout(() => this.errorMessage = err.message || err.toString());
return of('...'); // reset message to placeholder
})
);
TwainComponent
会从一个注入进来的 TwainService
来获取这些引文。 在服务返回第一条引文之前,该组件会先返回一个占位值('...'
)的 Observable
。
The TwainComponent
gets quotes from an injected TwainService
. The component starts the returned Observable
with a placeholder value ('...'
), before the service can returns its first quote.
catchError
会拦截服务中的错误,准备错误信息,并在成功分支中返回占位值。 它必须等一拍(tick)才能设置 errorMessage
,以免在同一个变更检测周期中两次修改这个消息而导致报错。
The catchError
intercepts service errors, prepares an error message, and returns the placeholder value on the success channel. It must wait a tick to set the errorMessage
in order to avoid updating that message twice in the same change detection cycle.
这就是你要测试的全部特性。
These are all features you'll want to test.
使用间谍(Spy)进行测试
Testing with a spy
当测试组件时,只应该关心服务的公共 API。 通常来说,测试不应该自己向远端服务器发起调用。 它们应该对这些调用进行仿真。app/twain/twain.component.spec.ts
中的准备代码展示了实现方式之一:
When testing a component, only the service's public API should matter. In general, tests themselves should not make calls to remote servers. They should emulate such calls. The setup in this app/twain/twain.component.spec.ts
shows one way to do that:
beforeEach(() => {
testQuote = 'Test Quote';
// Create a fake TwainService object with a `getQuote()` spy
const twainService = jasmine.createSpyObj('TwainService', ['getQuote']);
// Make the spy return a synchronous Observable with the test data
getQuoteSpy = twainService.getQuote.and.returnValue( of(testQuote) );
TestBed.configureTestingModule({
declarations: [ TwainComponent ],
providers: [
{ provide: TwainService, useValue: twainService }
]
});
fixture = TestBed.createComponent(TwainComponent);
component = fixture.componentInstance;
quoteEl = fixture.nativeElement.querySelector('.twain');
});
重点看这个间谍对象(spy)。
Focus on the spy.
// Create a fake TwainService object with a `getQuote()` spy
const twainService = jasmine.createSpyObj('TwainService', ['getQuote']);
// Make the spy return a synchronous Observable with the test data
getQuoteSpy = twainService.getQuote.and.returnValue( of(testQuote) );
这个间谍的设计是:任何对 getQuote
的调用都会收到一个包含测试引文的可观察对象。 和真正的 getQuote()
方法不同,这个间谍跳过了服务器,直接返回了一个能立即解析出值的同步型可观察对象。
The spy is designed such that any call to getQuote
receives an observable with a test quote. Unlike the real getQuote()
method, this spy bypasses the server and returns a synchronous observable whose value is available immediately.
虽然它的 Observable
是同步的,不过你仍然可以使用这个间谍对象写出很多有用的测试。
You can write many useful tests with this spy, even though its Observable
is synchronous.
同步测试
Synchronous tests
同步 Observable
的一大优点就是你可以把那些异步的流程转换成同步测试。
A key advantage of a synchronous Observable
is that you can often turn asynchronous processes into synchronous tests.
it('should show quote after component initialized', () => {
fixture.detectChanges(); // onInit()
// sync spy result shows testQuote immediately after init
expect(quoteEl.textContent).toBe(testQuote);
expect(getQuoteSpy.calls.any()).toBe(true, 'getQuote called');
});
因为间谍对象的结果是同步返回的,所以 getQuote()
方法会在 Angular 调用 ngOnInit
时触发的首次变更检测周期后立即修改屏幕上的消息。
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
.
但测试出错路径的时候就没这么幸运了。 虽然该服务的间谍也会返回一个同步的错误对象,但是组件的那个方法中调用了 setTimeout()
。 这个测试必须至少等待 JavaScript 引擎的一个周期,那个值才会变成可用状态。因此这个测试变成了异步的。
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.
使用 fakeAsync()
进行异步测试
Async test with fakeAsync()
要使用 fakeAsync()
功能,你需要导入 zone-testing
,欲知详情,参见环境准备指南。
To use fakeAsync()
functionality, you need to import zone-testing
, for details, please read setup guide.
下列测试用于确保当服务返回 ErrorObservable
的时候也能有符合预期的行为。
The following test confirms the expected behavior when the service returns an ErrorObservable
.
- it('should display error when TwainService fails', fakeAsync(() => {
- // tell spy to return an error observable
- getQuoteSpy.and.returnValue(
- throwError('TwainService test failure'));
-
- fixture.detectChanges(); // onInit()
- // sync spy errors immediately after init
-
- tick(); // flush the component's setTimeout()
-
- fixture.detectChanges(); // update errorMessage within setTimeout()
-
- expect(errorMessage()).toMatch(/test failure/, 'should display error');
- expect(quoteEl.textContent).toBe('...', 'should show placeholder');
- }));
注意这个 it()
函数接收了一个如下形式的参数。
Note that the it()
function receives an argument of the following form.
fakeAsync(() => { /* test body */ })`
fakeAsync
函数通过在一个特殊的fakeAsync
测试区域(zone)中运行测试体来启用线性代码风格。 测试体看上去是同步的。 这里没有嵌套式语法(如 Promise.then()
)来打断控制流。
The fakeAsync()
function enables a linear coding style by running the test body in a special fakeAsync test zone
. The test body appears to be synchronous. There is no nested syntax (like a Promise.then()
) to disrupt the flow of control.
tick()
函数
The tick() function
你必须调用 tick()
函数来向前推动(虚拟)时钟。
You do have to call tick()
to advance the (virtual) clock.
调用 tick()
会模拟时光的流逝,直到所有未决的异步活动都结束为止。 在这个例子中,它会等待错误处理器中的 setTimeout()
。
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()
函数接受一个毫秒值作为参数(如果没有提供则默认为 0)。该参数表示虚拟时钟要前进多少。 比如,如果你的 fakeAsync()
测试中有一个 setTimeout(fn, 100)
函数,你就需要用 tick(100)
来触发它的 fn 回调。
The tick()
function accepts milliseconds as parameter (defaults to 0 if not provided). The parameter represents how much the virtual clock advances. For example, if you have a setTimeout(fn, 100)
in a fakeAsync()
test, you need to use tick(100) to trigger the fn callback.
it('should run timeout callback with delay after call tick with millis', fakeAsync(() => {
let called = false;
setTimeout(() => { called = true; }, 100);
tick(100);
expect(called).toBe(true);
}));
tick()
函数是你从 TestBed
中导入的 Angular 测试实用工具之一。 它和 fakeAsync()
一同使用,并且你只能在 fakeAsync()
体中调用它。
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.
在 fakeAsync()
中比较日期(date)
Comparing dates inside fakeAsync()
fakeAsync()
可以模拟时光的流逝,它允许你在 fakeAsync()
中计算日期之间的差异。
fakeAsync()
simulates passage of time, which allows you to calculate the difference between dates inside fakeAsync()
.
it('should get Date diff correctly in fakeAsync', fakeAsync(() => {
const start = Date.now();
tick(100);
const end = Date.now();
expect(end - start).toBe(100);
}));
jasmine.clock
与 fakeAsync()
jasmine.clock with fakeAsync()
Jasmine 也提供了 clock
特性来模拟日期。在 fakeAsync()
方法内,Angular 会自动运行那些调用 jasmine.clock().install()
和调用 jasmine.clock().uninstall()
之间的测试。fakeAsync()
不是必须的,而且如果嵌套它会抛出错误。
Jasmine also provides a clock
feature to mock dates. Angular automatically runs tests that are run after jasmine.clock().install()
is called inside a fakeAsync()
method until jasmine.clock().uninstall()
is called. fakeAsync()
is not needed and throws an error if nested.
默认情况下,该特性是禁用的。要启用它,请在导入 zone-testing
之前设置一个全局标志。
By default, this feature is disabled. To enable it, set a global flag before import zone-testing
.
如果你使用 Angular CLI,请在 src/test.ts
中配置此标志。
If you use the Angular CLI, configure this flag in src/test.ts
.
(window as any)['__zone_symbol__fakeAsyncPatchLock'] = true;
import 'zone.js/dist/zone-testing';
- describe('use jasmine.clock()', () => {
- // need to config __zone_symbol__fakeAsyncPatchLock flag
- // before loading zone.js/dist/zone-testing
- beforeEach(() => { jasmine.clock().install(); });
- afterEach(() => { jasmine.clock().uninstall(); });
- it('should auto enter fakeAsync', () => {
- // is in fakeAsync now, don't need to call fakeAsync(testFn)
- let called = false;
- setTimeout(() => { called = true; }, 100);
- jasmine.clock().tick(100);
- expect(called).toBe(true);
- });
- });
在 fakeAsync()
内使用 RxJS 调度器(scheduler)
Using the RxJS scheduler inside fakeAsync()
你还可以在 fakeAsync()
中使用 RxJS 调度器,就像 setTimeout()
或 setInterval()
一样,但是你要导入 zone.js/dist/zone-patch-rxjs-fake-async
来 patch 掉 RxJS 的调度器。
You can also use RxJS scheduler in fakeAsync()
just like using setTimeout()
or setInterval()
, but you need to import zone.js/dist/zone-patch-rxjs-fake-async
to patch RxJS scheduler.
- it('should get Date diff correctly in fakeAsync with rxjs scheduler', fakeAsync(() => {
- // need to add `import 'zone.js/dist/zone-patch-rxjs-fake-async'
- // to patch rxjs scheduler
- let result = null;
- of ('hello').pipe(delay(1000)).subscribe(v => { result = v; });
- expect(result).toBeNull();
- tick(1000);
- expect(result).toBe('hello');
-
- const start = new Date().getTime();
- let dateDiff = 0;
- interval(1000).pipe(take(2)).subscribe(() => dateDiff = (new Date().getTime() - start));
-
- tick(1000);
- expect(dateDiff).toBe(1000);
- tick(1000);
- expect(dateDiff).toBe(2000);
- }));
支持更多宏任务(macroTasks)
Support more macroTasks
默认情况下,fakeAsync()
支持下列 macroTasks
。
By default fakeAsync()
supports the following macroTasks
.
- setTimeout
- setInterval
- requestAnimationFrame
- webkitRequestAnimationFrame
- mozRequestAnimationFrame
如果你运行其它 macroTasks
(比如 HTMLCanvasElement.toBlob()
)就会抛出一条 Unknown macroTask scheduled in fake async test
错误。
If you run other macroTask
such as HTMLCanvasElement.toBlob()
, Unknown macroTask scheduled in fake async test
error will be thrown.
import { TestBed, async, tick, fakeAsync } from '@angular/core/testing';
import { CanvasComponent } from './canvas.component';
describe('CanvasComponent', () => {
beforeEach(async(() => {
TestBed.configureTestingModule({
declarations: [
CanvasComponent
],
}).compileComponents();
}));
beforeEach(() => {
window['__zone_symbol__FakeAsyncTestMacroTask'] = [
{
source: 'HTMLCanvasElement.toBlob',
callbackArgs: [{ size: 200 }]
}
];
});
it('should be able to generate blob data from canvas', fakeAsync(() => {
const fixture = TestBed.createComponent(CanvasComponent);
fixture.detectChanges();
tick();
const app = fixture.debugElement.componentInstance;
expect(app.blobSize).toBeGreaterThan(0);
}));
});
如果你要支持这种情况,就要在 beforeEach()
中定义你要支持的 macroTask
。比如:
If you want to support such case, you need to define the macroTask
you want to support in beforeEach()
. For example:
- beforeEach(() => {
- window['__zone_symbol__FakeAsyncTestMacroTask'] = [
- {
- source: 'HTMLCanvasElement.toBlob',
- callbackArgs: [{ size: 200 }]
- }
- ];
- });
-
- it('toBlob should be able to run in fakeAsync', fakeAsync(() => {
- const canvas: HTMLCanvasElement = document.getElementById('canvas') as HTMLCanvasElement;
- let blob = null;
- canvas.toBlob(function(b) {
- blob = b;
- });
- tick();
- expect(blob.size).toBe(200);
- })
- );
异步的可观察对象
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.
如果你在 getQuote()
间谍中返回一个异步可观察对象,那它就能更忠诚的反映出真实的世界了。
Your tests will reflect the real world more faithfully if you return an asynchronous observable from the getQuote()
spy like this.
// Simulate delayed observable values with the `asyncData()` helper
getQuoteSpy.and.returnValue(asyncData(testQuote));
可观察对象的异步助手
Async observable helpers
这个异步的可观察对象是用 asyncData
辅助函数生成的。 asyncData
助手是一个工具函数,你可以自己写一个,也可以从下面的范例代码中复制一份。
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.
/** Create async observable that emits-once and completes
* after a JS engine turn */
export function asyncData<T>(data: T) {
return defer(() => Promise.resolve(data));
}
这个辅助函数的可观察对象会在 JavaScript 引擎的下一个工作周期中发出 data
的值。
This helper's observable emits the data
value in the next turn of the JavaScript engine.
RxJS 的 defer()
(延期)操作符 会返回一个可观察对象。 它获取一个工厂函数,这个工厂函数或者返回 Promise 或者返回 Observable。 当有人订阅了这个 defer
的可观察对象时,它就会把这个订阅者添加到由那个工厂函数创建的新的可观察对象中。
The RxJS defer()
operator returns an observable. It takes a factory function that returns either a promise or an observable. When something subscribes to defer's observable, it adds the subscriber to a new observable created with that factory.
defer()
操作符会把 Promise.resolve()
转换成一个新的可观察对象,然后像 HttpClient
那样的发出一个值,然后结束。 订阅者将会在接收到这个数据值之后自动被取消订阅。
The defer()
operator transforms the Promise.resolve()
into a new observable that, like HttpClient
, emits once and completes. Subscribers are unsubscribed after they receive the data value.
下面是一个类似的用于产生异步错误的辅助函数。
There's a similar helper for producing an async error.
/** Create async observable error that errors
* after a JS engine turn */
export function asyncError<T>(errorObject: any) {
return defer(() => Promise.reject(errorObject));
}
更多异步测试
More async tests
现在,getQuote()
间谍会返回一个异步的可观察对象,你的大多数测试也同样要变成异步的。
Now that the getQuote()
spy is returning async observables, most of your tests will have to be async as well.
下面这个 fakeAsync()
测试演示了你所期待的和真实世界中一样的数据流。
Here's a fakeAsync()
test that demonstrates the data flow you'd expect in the real world.
it('should show quote after getQuote (fakeAsync)', fakeAsync(() => {
fixture.detectChanges(); // ngOnInit()
expect(quoteEl.textContent).toBe('...', 'should show placeholder');
tick(); // flush the observable to get the quote
fixture.detectChanges(); // update view
expect(quoteEl.textContent).toBe(testQuote, 'should show quote');
expect(errorMessage()).toBeNull('should not show error');
}));
注意,这个 <quote>
元素应该在 ngOnInit()
之后显示占位值('...'
), 但第一个引文却没有出现。
Notice that the quote element displays the placeholder value ('...'
) after ngOnInit()
. The first quote hasn't arrived yet.
要刷出可观察对象中的第一个引文,你就要先调用 tick()
,然后调用 detectChanges()
来要求 Angular 刷新屏幕。
To flush the first quote from the observable, you call tick()
. Then call detectChanges()
to tell Angular to update the screen.
然后你就可以断言这个 <quote>
元素应该显示所预期的文字了。
Then you can assert that the quote element displays the expected text.
使用 async()
进行异步测试
Async test with async()
要使用 async()
功能,你需要导入 zone-testing
,欲知详情,参见环境准备指南。
To use async()
functionality, you need to import zone-testing
, for details, please read setup guide.
fakeAsync()
工具函数有一些限制。 特别是,如果测试中发起了 XHR
调用,它就没用了。
The fakeAsync()
utility function has a few limitations. In particular, it won't work if the test body makes an XHR
call.
测试中的 XHR
调用比较罕见,所以你通常会使用 fakeAsync()
。 不过你可能迟早会需要调用 XHR
,那就来了解一些 async()
的知识吧。
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()
.
TestBed.compileComponents()
方法(参见稍后)就会在 JIT 编译期间调用 XHR
来读取外部模板和 CSS 文件。 如果写调用了 compileComponents()
的测试,就要用到 async()
工具函数了。
The TestBed.compileComponents()
method (see below) calls XHR
to read external template and css files during "just-in-time" compilation. Write tests that call compileComponents()
with the async()
utility.
下面是用 async()
工具函数重写的以前的 fakeAsync()
测试。
Here's the previous fakeAsync()
test, re-written with the async()
utility.
it('should show quote after getQuote (async)', async(() => {
fixture.detectChanges(); // ngOnInit()
expect(quoteEl.textContent).toBe('...', 'should show placeholder');
fixture.whenStable().then(() => { // wait for async getQuote
fixture.detectChanges(); // update view with quote
expect(quoteEl.textContent).toBe(testQuote);
expect(errorMessage()).toBeNull('should not show error');
});
}));
async()
工具函数通过把测试人员的代码放进在一个特殊的async 测试区域中,节省了一些用于异步调用的样板代码。 你不必把 Jasmine 的 done()
传给这个测试,并在承诺(Promise)或可观察对象的回调中调用 done()
。
The async()
utility hides some asynchronous boilerplate by arranging for the tester's code to run in a special async test zone. You don't need to pass Jasmine's done()
into the test and call done()
because it is undefined
in promise or observable callbacks.
但是对 fixture.whenStable()
的调用揭示了该测试的异步本性,它将会打破线性的控制流。
But the test's asynchronous nature is revealed by the call to fixture.whenStable()
, which breaks the linear flow of control.
当要在 async()
中使用 setInterval()
之类的 intervalTimer()
时,别忘了在测试完成之后调用 clearInterval()
来取消定时器,否则 async()
永远不会结束。
When using an intervalTimer()
such as setInterval()
in async()
, remember to cancel the timer with clearInterval()
after the test, otherwise the async()
never ends.
whenStable
该测试必须等待 getQuote()
的可观察对象发出下一条引言。 它不再调用 tick()
,而是调用 fixture.whenStable()
。
The test must wait for the getQuote()
observable to emit the next quote. Instead of calling tick()
, it calls fixture.whenStable()
.
fixture.whenStable()
返回一个承诺,这个承诺会在 JavaScript 引擎的任务队列变为空白时被解析。 在这个例子中,一旦这个可观察对象发出了第一条引言,这个任务队列就会变为空。
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.
该测试在这个承诺的回调中继续执行,它会调用 detectChanges()
来用预期的文本内容修改 <quote>
元素。
The test resumes within the promise callback, which calls detectChanges()
to update the quote element with the expected text.
Jasmine done()
虽然 async
和 fakeAsync
函数极大地简化了 Angular 的异步测试,不过你仍然可以回退到传统的技术中。 也就是说给 it
额外传入一个函数型参数,这个函数接受一个 done
回调。
While the async()
and fakeAsync()
functions greatly simplify Angular asynchronous testing, you can still fall back to the traditional technique and pass it
a function that takes a done
callback.
但你不能在 async()
或 fakeAsync()
函数中调用 done()
,因为它的 done
参数是 undefined
。
You can't call done()
in async()
or fakeAsync()
functions, because the done parameter
is undefined
.
现在,你就要负责对 Promise 进行链接、处理错误,并在适当的时机调用 done()
了。
Now you are responsible for chaining promises, handling errors, and calling done()
at the appropriate moments.
写带有 done()
的测试函数会比 async
和 fakeAsync
方式更加冗长。 不过有些时候它是必要的。 比如,你不能在那些涉及到 intervalTimer()
或 RxJS 的 delay()
操作符时调用 async
或 fakeAsync
函数。
Writing test functions with done()
, is more cumbersome than async()
and fakeAsync()
. But it is occasionally necessary when code involves the intervalTimer()
like setInterval
.
下面是对前面的测试用 done()
重写后的两个版本。 第一个会订阅由组件的 quote
属性暴露给模板的那个 Observable
。
Here are two more 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.
it('should show last quote (quote done)', (done: DoneFn) => {
fixture.detectChanges();
component.quote.pipe( last() ).subscribe(() => {
fixture.detectChanges(); // update view with quote
expect(quoteEl.textContent).toBe(testQuote);
expect(errorMessage()).toBeNull('should not show error');
done();
});
});
RxJS 的 last()
操作符会在结束之前发出这个可观察对象的最后一个值,也就是那条测试引文。 subscribe
回调中会像以前一样调用 detectChanges()
用这条测试引文更新 <quote>
元素。
The RxJS last()
operator emits the observable's last value before completing, which will be the test quote. The subscribe
callback calls detectChanges()
to update the quote element with the test quote, in the same manner as the earlier tests.
有些测试中,相对于在屏幕上展示了什么,你可能会更关心所注入服务的某个方法是如何被调用的,以及它的返回值是什么。
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.
服务的间谍,比如假冒服务 TwainService
的 getQuote()
间谍,可以给你那些信息,并且对视图的状态做出断言。
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.
it('should show quote after getQuote (spy done)', (done: DoneFn) => {
fixture.detectChanges();
// the spy's most recent call returns the observable with the test quote
getQuoteSpy.calls.mostRecent().returnValue.subscribe(() => {
fixture.detectChanges(); // update view with quote
expect(quoteEl.textContent).toBe(testQuote);
expect(errorMessage()).toBeNull('should not show error');
done();
});
});
组件的弹珠测试
Component marble tests
前面的 TwainComponent
测试中使用 TwainService
中的 asyncData
和 asyncError
工具函数仿真了可观察对象的异步响应。
The previous TwainComponent
tests simulated an asynchronous observable response from the TwainService
with the asyncData
and asyncError
utilities.
那些都是你自己写的简短函数。 很不幸,它们对于很多常见场景来说都太过简单了。 可观察对象通常会发出很多次值,还可能会在显著的延迟之后。 组件可能要协调多个由正常值和错误值组成的重叠序列的可观察对象。
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 的弹珠测试是测试各种可观察对象场景的最佳方式 —— 无论简单还是复杂。 你可以看看弹珠图,它揭示了可观察对象的工作原理。 弹珠测试使用类似的弹珠语言来在你的测试中指定可观察对象流和对它们的期待。
RxJS marble testing is a great way to test observable scenarios, both simple and complex. You've likely seen the marble diagrams that illustrate how observables work. Marble testing uses a similar marble language to specify the observable streams and expectations in your tests.
下面的例子使用弹珠测试重写了 TwainComponent
的两个测试。
The following examples revisit two of the TwainComponent
tests with marble testing.
首先安装 jasmine-marbles
这个 npm 包,然后倒入所需的符号。
Start by installing the jasmine-marbles
npm package. Then import the symbols you need.
import { cold, getTestScheduler } from 'jasmine-marbles';
下面是对获取引文功能的完整测试:
Here's the complete test for getting a quote:
it('should show quote after getQuote (marbles)', () => {
// observable test quote value and complete(), after delay
const q$ = cold('---x|', { x: testQuote });
getQuoteSpy.and.returnValue( q$ );
fixture.detectChanges(); // ngOnInit()
expect(quoteEl.textContent).toBe('...', 'should show placeholder');
getTestScheduler().flush(); // flush the observables
fixture.detectChanges(); // update view
expect(quoteEl.textContent).toBe(testQuote, 'should show quote');
expect(errorMessage()).toBeNull('should not show error');
});
注意,这个 Jasmine 测试是同步的。没有调用 fakeAsync()
。 弹珠测试使用了一个测试调度程序来用同步的方式模拟时间的流逝。
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.
弹珠测试的美妙之处在于它给出了可观察对象流的可视化定义。 这个测试定义了一个冷的可观察对象,它等待三帧 (---
),然后发出一个值(x
),然后结束(|
)。 在第二个参数中,你把值标记(x
)换成了实际发出的值(testQuote
)。
The beauty of marble testing is in the visual definition of the observable streams. This test defines a cold observable that waits three frames (---
), emits a value (x
), and completes (|
). In the second argument you map the value marker (x
) to the emitted value (testQuote
).
const q$ = cold('---x|', { x: testQuote });
这个弹珠库会构造出相应的可观察对象,测试代码会把它当做 getQuote
间谍的返回值。
The marble library constructs the corresponding observable, which the test sets as the getQuote
spy's return value.
当你已经准备好激活这个弹珠库构造出的可观察对象时,只要让 TestScheduler
去刷新准备好的任务队列就可以了。代码如下:
When you're ready to activate the marble observables, you tell the TestScheduler
to flush its queue of prepared tasks like this.
getTestScheduler().flush(); // flush the observables
这个步骤的目的类似于前面的 fakeAsync()
和 async()
范例中的 tick()
和 whenStable()
。 这种测试的权衡方式也和那些例子中是一样的。
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.
弹珠错误测试
Marble error testing
下面是 getQuote()
错误测试的弹珠测试版本。
Here's the marble testing version of the getQuote()
error test.
it('should display error when TwainService fails', fakeAsync(() => {
// observable error after delay
const q$ = cold('---#|', null, new Error('TwainService test failure'));
getQuoteSpy.and.returnValue( q$ );
fixture.detectChanges(); // ngOnInit()
expect(quoteEl.textContent).toBe('...', 'should show placeholder');
getTestScheduler().flush(); // flush the observables
tick(); // component shows error after a setTimeout()
fixture.detectChanges(); // update error message
expect(errorMessage()).toMatch(/test failure/, 'should display error');
expect(quoteEl.textContent).toBe('...', 'should show placeholder');
}));
它仍然是异步测试,要调用 fakeAsync()
和 tick()
,这是因为组件自身在处理错误的时候调用 setTimeout()
。
It's still an async test, calling fakeAsync()
and tick()
, because the component itself calls setTimeout()
when processing errors.
看看弹珠库生成的可观察对象的定义。
Look at the marble observable definition.
const q$ = cold('---#|', null, new Error('TwainService test failure'));
它是一个冷的可观察对象,它等待三帧,然后发出一个错误。 井号(#
)标记出了发出错误的时间点,这个错误是在第三个参数中指定的。 第二个参数是空的,因为这个可观察对象永远不会发出正常值。
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
弹珠帧是测试时序中的虚拟单元。 每个符号(-
,x
,|
,#
)都表示一帧过去了。
A marble frame is a virtual unit of testing time. Each symbol (-
, x
, |
, #
) marks the passing of one frame.
冷的可观察对象不会生成值,除非你订阅它。 应用中的大多数可观察对象都是冷的。 所有 HttpClient
的方法返回的都是冷的可观察对象。
A cold observable doesn't produce values until you subscribe to it. Most of your application observables are cold. All HttpClient methods return cold observables.
热的可观察对象在你订阅它之前就会生成值。 Router.events
可观察对象会主动汇报路由器的活动,它就是个热的可观察对象。
A hot observable is already producing values before you subscribe to it. The Router.events observable, which reports router activity, is a hot observable.
RxJS 的弹珠测试是一个内容丰富的主题,超出了本章的范围。 要想在网络上进一步学习它,可以从 official documentation 开始。
RxJS marble testing is a rich subject, beyond the scope of this guide. Learn about it on the web, starting with the official documentation.
带有输入输出参数的组件
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.
测试的目的是验证这样的绑定和期待的那样正常工作。 测试程序应该设置导入值并监听导出事件。
The testing goal is to verify that such bindings work as expected. The tests should set input values and listen for output events.
DashboardHeroComponent
是非常小的这种类型的例子组件。 它显示由 DashboardCompoent
提供的英雄个体。 点击英雄告诉 DashbaordComponent
用户已经选择了这个英雄。
The DashboardHeroComponent
is a tiny example of a component in this role. It displays an individual hero provided by the DashboardComponent
. Clicking that hero tells the DashboardComponent
that the user has selected the hero.
DashboardHeroComponent
是这样内嵌在 DashboardCompoent
的模板中的:
The DashboardHeroComponent
is embedded in the DashboardComponent
template like this:
<dashboard-hero *ngFor="let hero of heroes" class="col-1-4"
[hero]=hero (selected)="gotoDetail($event)" >
</dashboard-hero>
DashboardHeroComponent
在 *ngFor
循环中出现,把每个组件的 hero
input 属性设置为迭代的值,并监听组件的 selected
事件。
The DashboardHeroComponent
appears in an *ngFor
repeater, which sets each component's hero
input property to the looping value and listens for the component's selected
event.
下面是该组件的完整定义:
Here's the component's full definition:
@Component({
selector: 'dashboard-hero',
template: `
<div (click)="click()" class="hero">
{{hero.name | uppercase}}
</div>`,
styleUrls: [ './dashboard-hero.component.css' ]
})
export class DashboardHeroComponent {
@Input() hero: Hero;
@Output() selected = new EventEmitter<Hero>();
click() { this.selected.emit(this.hero); }
}
虽然测试这么简单的组件没有什么内在价值,但是它的测试程序是值得学习的。 有下列候选测试方案:
While testing a component this simple has little intrinsic value, it's worth knowing how. You can use one of these approaches:
把它当作被
DashbaordComponent
使用的组件来测试Test it as used by
DashboardComponent
.把它当作独立的组件来测试
Test it as a stand-alone component.
把它当作被
DashbaordComponent
的替代组件使用的组件来测试Test it as used by a substitute for
DashboardComponent
.
简单看看 DashbaordComponent
的构造函数就否决了第一种方案:
A quick look at the DashboardComponent
constructor discourages the first approach:
constructor(
private router: Router,
private heroService: HeroService) {
}
DashbaordComponent
依赖 Angular 路由器和 HeroService
服务。 你必须使用测试替身替换它们两个,似乎过于复杂了。 路由器尤其具有挑战性。
The DashboardComponent
depends on the Angular router and the HeroService
. You'd probably have to replace them both with test doubles, which is a lot of work. The router seems particularly challenging.
稍后的讨论涵盖了那些需要路由器的测试组件。
The discussion below covers testing components that require the router.
当前的任务是测试 DashboardHeroComponent
组件,而非 DashbaordComponent
,所以无需做不必要的努力。 那就试试第二和第三种方案。
The immediate goal is to test the DashboardHeroComponent
, not the DashboardComponent
, so, try the second and third options.
单独测试 DashboardHeroComponent
Test DashboardHeroComponent stand-alone
下面是 spec 文件的准备语句中的重点部分。
Here's the meat of the spec file setup.
TestBed.configureTestingModule({
declarations: [ DashboardHeroComponent ]
})
fixture = TestBed.createComponent(DashboardHeroComponent);
comp = fixture.componentInstance;
// find the hero's DebugElement and element
heroDe = fixture.debugElement.query(By.css('.hero'));
heroEl = heroDe.nativeElement;
// mock the hero supplied by the parent component
expectedHero = { id: 42, name: 'Test Name' };
// simulate the parent setting the input property with that hero
comp.hero = expectedHero;
// trigger initial data binding
fixture.detectChanges();
注意代码是如何将模拟英雄(expectedHero
)赋值给组件的 hero
属性的,模拟了 DashbaordComponent
在它的迭代器中通过属性绑定的赋值方式。
Note how the setup code assigns a test hero (expectedHero
) to the component's hero
property, emulating the way the DashboardComponent
would set it via the property binding in its repeater.
下面的测试会验证英雄的名字已经通过绑定的方式传播到模板中了。
The following test verifies that the hero name is propagated to the template via a binding.
it('should display hero name in uppercase', () => {
const expectedPipedName = expectedHero.name.toUpperCase();
expect(heroEl.textContent).toContain(expectedPipedName);
});
因为模板通过 Angular 的 UpperCasePipe
传入了英雄的名字,所以这个测试必须匹配该元素的值中包含了大写形式的名字。
Because the template passes the hero name through the Angular UpperCasePipe
, the test must match the element value with the upper-cased name.
这个小测试示范了 Angular 的测试如何以较低的成本验证组件的视觉表现(它们不能通过组件类测试进行验证)。 而不用借助那些更慢、更复杂的端到端测试。
This small test demonstrates how Angular tests can verify a component's visual representation—something not possible with component class tests—at low cost and without resorting to much slower and more complicated end-to-end tests.
点击
Clicking
点击这个英雄将会发出一个 selected
事件,而宿主元素(可能是 DashboardComponent
)可能会听到它:
Clicking the hero should raise a selected
event that the host component (DashboardComponent
presumably) can hear:
it('should raise selected event when clicked (triggerEventHandler)', () => {
let selectedHero: Hero;
comp.selected.subscribe((hero: Hero) => selectedHero = hero);
heroDe.triggerEventHandler('click', null);
expect(selectedHero).toBe(expectedHero);
});
该组件的 selected
属性返回一个 EventEmitter
,对消费者来说它和 RxJS 的同步 Observable
很像。 该测试会显式订阅它,而宿主组件会隐式订阅它。
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
属性发出这个 hero
对象。
If the component behaves as expected, clicking the hero's element should tell the component's selected
property to emit the hero
object.
这个测试会通过订阅 selected
来检测是否确实如此。
The test detects that event through its subscription to selected
.
triggerEventHandler
前面测试中的 heroDe
是一个指向英雄条目 <div>
的 DebugElement
。
The heroDe
in the previous test is a DebugElement
that represents the hero <div>
.
它有一些用于抽象与原生元素交互的 Angular 属性和方法。 这个测试会使用事件名称 click
来调用 DebugElement.triggerEventHandler
。 click
的事件绑定到了 DashboardHeroComponent.click()
。
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 的 DebugElement.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.
该测试使用事件对象 null
触发了一次 click
事件。
The test triggered a "click" event with a null
event object.
heroDe.triggerEventHandler('click', 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.
其它处理器的要求比较严格。比如,RouterLink
指令期望一个带有 button
属性的对象,该属性用于指出点击时按下的是哪个鼠标按钮。 如果不给出这个事件对象,RouterLink
指令就会抛出一个错误。
Other handlers are less forgiving. For example, the RouterLink
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.
点击该元素
Click the element
下面这个测试改为调用原生元素自己的 click()
方法,它对于这个组件来说相当完美。
The following test alternative calls the native element's own click()
method, which is perfectly fine for this component.
it('should raise selected event when clicked (element.click)', () => {
let selectedHero: Hero;
comp.selected.subscribe((hero: Hero) => selectedHero = hero);
heroEl.click();
expect(selectedHero).toBe(expectedHero);
});
click() 辅助函数
click() helper
点击按钮、链接或者任意 HTML 元素是很常见的测试任务。
Clicking a button, an anchor, or an arbitrary HTML element is a common test task.
把点击事件的处理过程包装到如下的 click()
辅助函数中,可以让这项任务更一致、更简单:
Make that consistent and easy by encapsulating the click-triggering process in a helper such as the click()
function below:
/** Button events to pass to `DebugElement.triggerEventHandler` for RouterLink event handler */
export const ButtonClickEvents = {
left: { button: 0 },
right: { button: 2 }
};
/** Simulate element click. Defaults to mouse left-button click event. */
export function click(el: DebugElement | HTMLElement, eventObj: any = ButtonClickEvents.left): void {
if (el instanceof HTMLElement) {
el.click();
} else {
el.triggerEventHandler('click', eventObj);
}
}
第一个参数是用来点击的元素。如果你愿意,可以将自定义的事件对象传递给第二个参数。 默认的是(局部的)鼠标左键事件对象, 它被许多事件处理器接受,包括 RouterLink
指令。
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.
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
辅助函数重写后的版本。
Here's the previous test, rewritten using the click helper.
it('should raise selected event when clicked (click helper)', () => {
let selectedHero: Hero;
comp.selected.subscribe(hero => selectedHero = hero);
click(heroDe); // click helper with DebugElement
click(heroEl); // click helper with native element
expect(selectedHero).toBe(expectedHero);
});
位于测试宿主中的组件
Component inside a test host
前面的这些测试都是自己扮演宿主元素 DashboardComponent
的角色。 但是当 DashboardHeroComponent
真的绑定到某个宿主元素时还能正常工作吗?
The previous tests played the role of the host DashboardComponent
themselves. But does the DashboardHeroComponent
work correctly when properly data-bound to a host component?
固然,你也可以测试真实的 DashboardComponent
。 但要想这么做需要做很多准备工作,特别是它的模板中使用了某些特性,如 *ngFor
、 其它组件、布局 HTML、附加绑定、注入了多个服务的构造函数、如何用正确的方式与那些服务交互等。
You could test with the actual DashboardComponent
. But doing so could require a lot of setup, especially when its template features an *ngFor
repeater, other components, layout HTML, additional bindings, a constructor that injects multiple services, and it starts interacting with those services right away.
想出这么多需要努力排除的干扰,只是为了证明一点 —— 可以造出这样一个令人满意的测试宿主:
Imagine the effort to disable these distractions, just to prove a point that can be made satisfactorily with a test host like this one:
@Component({
template: `
<dashboard-hero
[hero]="hero" (selected)="onSelected($event)">
</dashboard-hero>`
})
class TestHostComponent {
hero: Hero = {id: 42, name: 'Test Name' };
selectedHero: Hero;
onSelected(hero: Hero) { this.selectedHero = hero; }
}
这个测试宿主像 DashboardComponent
那样绑定了 DashboardHeroComponent
,但是没有 Router
、 没有 HeroService
,也没有 *ngFor
。
This test host binds to DashboardHeroComponent
as the DashboardComponent
would but without the noise of the Router
, the HeroService
, or the *ngFor
repeater.
这个测试宿主使用其测试用的英雄设置了组件的输入属性 hero
。 它使用 onSelected
事件处理器绑定了组件的 selected
事件,其中把事件中发出的英雄记录到了 selectedHero
属性中。
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.
稍后,这个测试就可以轻松检查 selectedHero
以验证 DashboardHeroComponent.selected
事件确实发出了所期望的英雄。
Later, the tests will be able to easily check selectedHero
to verify that the DashboardHeroComponent.selected
event emitted the expected hero.
这个测试宿主中的准备代码和独立测试中的准备过程类似:
The setup for the test-host tests is similar to the setup for the stand-alone tests:
TestBed.configureTestingModule({
declarations: [ DashboardHeroComponent, TestHostComponent ]
})
// create TestHostComponent instead of DashboardHeroComponent
fixture = TestBed.createComponent(TestHostComponent);
testHost = fixture.componentInstance;
heroEl = fixture.nativeElement.querySelector('.hero');
fixture.detectChanges(); // trigger initial data binding
这个测试模块的配置信息有三个重要的不同点:
This testing module configuration shows three important differences:
它同时声明了
DashboardHeroComponent
和TestHostComponent
。It declares both the
DashboardHeroComponent
and theTestHostComponent
.它创建了
TestHostComponent
,而非DashboardHeroComponent
。It creates the
TestHostComponent
instead of theDashboardHeroComponent
.TestHostComponent
通过绑定机制设置了DashboardHeroComponent.hero
。The
TestHostComponent
sets theDashboardHeroComponent.hero
with a binding.
createComponent
返回的 fixture
里有 TestHostComponent
实例,而非 DashboardHeroComponent
组件实例。
The createComponent
returns a fixture
that holds an instance of TestHostComponent
instead of an instance of DashboardHeroComponent
.
当然,创建 TestHostComponent
有创建 DashboardHeroComponent
的副作用,因为后者出现在前者的模板中。 英雄元素(heroEl
)的查询语句仍然可以在测试 DOM 中找到它,尽管元素树比以前更深。
Creating the TestHostComponent
has the side-effect of creating a DashboardHeroComponent
because the latter appears within the template of the former. The query for the hero element (heroEl
) still finds it in the test DOM, albeit at greater depth in the element tree than before.
这些测试本身和它们的孤立版本几乎相同:
The tests themselves are almost identical to the stand-alone version:
it('should display hero name', () => {
const expectedPipedName = testHost.hero.name.toUpperCase();
expect(heroEl.textContent).toContain(expectedPipedName);
});
it('should raise selected event when clicked', () => {
click(heroEl);
// selected hero should be the same data bound hero
expect(testHost.selectedHero).toBe(testHost.hero);
});
只有 selected 事件的测试不一样。它确保被选择的 DashboardHeroComponent
英雄确实通过事件绑定被传递到宿主组件。
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.
路由组件
Routing component
所谓路由组件就是指会要求 Router
导航到其它组件的组件。 DashboardComponent
就是一个路由组件,因为用户可以通过点击仪表盘中的某个英雄按钮来导航到 HeroDetailComponent
。
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.
路由确实很复杂。 测试 DashboardComponent
看上去有点令人生畏,因为它牵扯到和 HeroService
一起注入进来的 Router
。
Routing is pretty complicated. Testing the DashboardComponent
seemed daunting in part because it involves the Router
, which it injects together with the HeroService
.
constructor(
private router: Router,
private heroService: HeroService) {
}
使用间谍来 Mock HeroService
是一个熟悉的故事。 但是 Router
的 API 很复杂,并且与其它服务和应用的前置条件纠缠在一起。它应该很难进行 Mock 吧?
Mocking the HeroService
with a spy is a familiar story. But the Router
has a complicated API and is entwined with other services and application preconditions. Might it be difficult to mock?
庆幸的是,在这个例子中不会,因为 DashboardComponent
并没有深度使用 Router
。
Fortunately, not in this case because the DashboardComponent
isn't doing much with the Router
gotoDetail(hero: Hero) {
let url = `/heroes/${hero.id}`;
this.router.navigateByUrl(url);
}
这是路由组件中的通例。 一般来说,你应该测试组件而不是路由器,应该只关心组件有没有根据给定的条件导航到正确的地址。
This is often the case with routing components. 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.
为这个组件的测试套件提供路由器的间谍就像提供 HeroService
的间谍一样简单。
Providing a router spy for this component test suite happens to be as easy as providing a HeroService
spy.
const routerSpy = jasmine.createSpyObj('Router', ['navigateByUrl']);
const heroServiceSpy = jasmine.createSpyObj('HeroService', ['getHeroes']);
TestBed.configureTestingModule({
providers: [
{ provide: HeroService, useValue: heroServiceSpy },
{ provide: Router, useValue: routerSpy }
]
})
下面这个测试会点击正在显示的英雄,并确认 Router.navigateByUrl
曾用所期待的 URL 调用过。
The following test clicks the displayed hero and confirms that Router.navigateByUrl
is called with the expected url.
it('should tell ROUTER to navigate when hero clicked', () => {
heroClick(); // trigger click on first inner <div class="hero">
// args passed to router.navigateByUrl() spy
const spy = router.navigateByUrl as jasmine.Spy;
const navArgs = spy.calls.first().args[0];
// expecting to navigate to id of the component's first hero
const id = comp.heroes[0].id;
expect(navArgs).toBe('/heroes/' + id,
'should nav to HeroDetail for first hero');
});
路由目标组件
Routed components
路由目标组件是指 Router
导航到的目标。 它测试起来可能很复杂,特别是当路由到的这个组件包含参数的时候。 HeroDetailComponent
就是一个路由目标组件,它是某个路由定义指向的目标。
A routed component is the destination of a Router
navigation. It can be trickier to test, especially when the route to the component includes parameters. The HeroDetailComponent
is a routed component that is the destination of such a route.
当用户点击仪表盘中的英雄时,DashboardComponent
会要求 Router
导航到 heroes/:id
。 :id
是一个路由参数,它的值就是所要编辑的英雄的 id
。
When a user clicks a Dashboard hero, the DashboardComponent
tells the Router
to navigate to heroes/:id
. The :id
is a route parameter whose value is the id
of the hero to edit.
该 Router
会根据那个 URL 匹配到一个指向 HeroDetailComponent
的路由。 它会创建一个带有路由信息的 ActivatedRoute
对象,并把它注入到一个 HeroDetailComponent
的新实例中。
The Router
matches that URL to a route to the HeroDetailComponent
. It creates an ActivatedRoute
object with the routing information and injects it into a new instance of the HeroDetailComponent
.
下面是 HeroDetailComponent
的构造函数:
Here's the HeroDetailComponent
constructor:
constructor(
private heroDetailService: HeroDetailService,
private route: ActivatedRoute,
private router: Router) {
}
HeroDetailComponent
组件需要一个 id
参数,以便通过 HeroDetailService
获取相应的英雄。 该组件只能从 ActivatedRoute.paramMap
属性中获取这个 id
,这个属性是一个 Observable
。
The HeroDetail
component needs the id
parameter so it can fetch the corresponding hero via the HeroDetailService
. The component has to get the id
from the ActivatedRoute.paramMap
property which is an Observable
.
它不能仅仅引用 ActivatedRoute.paramMap
的 id
属性。 该组件不得不订阅 ActivatedRoute.paramMap
这个可观察对象,要做好它在生命周期中随时会发生变化的准备。
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.
ngOnInit(): void {
// get hero when `id` param changes
this.route.paramMap.subscribe(pmap => this.getHero(pmap.get('id')));
}
路由与导航一章中详细讲解了 ActivatedRoute.paramMap
。
The Router guide covers ActivatedRoute.paramMap
in more detail.
通过操纵注入到组件构造函数中的这个 ActivatedRoute
,测试可以探查 HeroDetailComponent
是如何对不同的 id
参数值做出响应的。
Tests can explore how the HeroDetailComponent
responds to different id
parameter values by manipulating the ActivatedRoute
injected into the component's constructor.
你已经知道了如何给 Router
和数据服务安插间谍。
You know how to spy on the Router
and a data service.
不过对于 ActivatedRoute
,你要采用另一种方式,因为:
You'll take a different approach with ActivatedRoute
because
在测试期间,
paramMap
会返回一个能发出多个值的Observable
。paramMap
returns anObservable
that can emit more than one value during a test.你需要路由器的辅助函数
convertToParamMap()
来创建ParamMap
。You need the router helper function,
convertToParamMap()
, to create aParamMap
.针对路由目标组件的其它测试需要一个
ActivatedRoute
的测试替身。Other routed components tests need a test double for
ActivatedRoute
.
这些差异表明你需要一个可复用的桩类(stub)。
These differences argue for a re-usable stub class.
ActivatedRouteStub
下面的 ActivatedRouteStub
类就是作为 ActivatedRoute
类的测试替身使用的。
The following ActivatedRouteStub
class serves as a test double for ActivatedRoute
.
import { convertToParamMap, ParamMap, Params } from '@angular/router';
import { ReplaySubject } from 'rxjs';
/**
* An ActivateRoute test double with a `paramMap` observable.
* Use the `setParamMap()` method to add the next `paramMap` value.
*/
export class ActivatedRouteStub {
// Use a ReplaySubject to share previous values with subscribers
// and pump new values into the `paramMap` observable
private subject = new ReplaySubject<ParamMap>();
constructor(initialParams?: Params) {
this.setParamMap(initialParams);
}
/** The mock paramMap observable */
readonly paramMap = this.subject.asObservable();
/** Set the paramMap observables's next value */
setParamMap(params?: Params) {
this.subject.next(convertToParamMap(params));
};
}
考虑把这类辅助函数放进一个紧邻 app
文件夹的 testing
文件夹。 这个例子把 ActivatedRouteStub
放在了 testing/activated-route-stub.ts
中。
Consider placing such helpers in a testing
folder sibling to the app
folder. This sample puts ActivatedRouteStub
in testing/activated-route-stub.ts
.
可以考虑使用弹珠测试库来为此测试桩编写一个更强力的版本。
Consider writing a more capable version of this stub class with the marble testing library.
使用 ActivatedRouteStub
进行测试
Testing with ActivatedRouteStub
下面的测试程序是演示组件在被观察的 id
指向现有英雄时的行为:
Here's a test demonstrating the component's behavior when the observed id
refers to an existing hero:
describe('when navigate to existing hero', () => {
let expectedHero: Hero;
beforeEach(async(() => {
expectedHero = firstHero;
activatedRoute.setParamMap({ id: expectedHero.id });
createComponent();
}));
it('should display that hero\'s name', () => {
expect(page.nameDisplay.textContent).toBe(expectedHero.name);
});
});
createComponent()
方法和 page
对象会在稍后进行讨论。 不过目前,你只要凭直觉来理解就行了。
The createComponent()
method and page
object are discussed below. Rely on your intuition for now.
当找不到 id
的时候,组件应该重新路由到 HeroListComponent
。
When the id
cannot be found, the component should re-route to the HeroListComponent
.
测试套件的准备代码提供了一个和前面一样的路由器间谍,它会充当路由器的角色,而不用发起实际的导航。
The test suite setup provided the same router spy described above which spies on the router without actually navigating.
这个测试中会期待该组件尝试导航到 HeroListComponent
。
This test expects the component to try to navigate to the HeroListComponent
.
describe('when navigate to non-existent hero id', () => {
beforeEach(async(() => {
activatedRoute.setParamMap({ id: 99999 });
createComponent();
}));
it('should try to navigate back to hero list', () => {
expect(page.gotoListSpy.calls.any()).toBe(true, 'comp.gotoList called');
expect(page.navigateSpy.calls.any()).toBe(true, 'router.navigate called');
});
});
虽然本应用没有在缺少 id
参数的时候,继续导航到 HeroDetailComponent
的路由,但是,将来它可能会添加这样的路由。 当没有 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
为零,name
为空。本测试程序确认组件是按照预期的这样做的:
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:
describe('when navigate with no hero id', () => {
beforeEach(async( createComponent ));
it('should have hero.id === 0', () => {
expect(component.hero.id).toBe(0);
});
it('should display empty hero name', () => {
expect(page.nameDisplay.textContent).toBe('');
});
});
对嵌套组件的测试
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.
比如,AppComponent
会显示一个带有链接及其 RouterLink
指令的导航条。
The AppComponent
, for example, displays a navigation bar with anchors and their RouterLink
directives.
<app-banner></app-banner>
<app-welcome></app-welcome>
<nav>
<a routerLink="/dashboard">Dashboard</a>
<a routerLink="/heroes">Heroes</a>
<a routerLink="/about">About</a>
</nav>
<router-outlet></router-outlet>
虽然 AppComponent
类是空的,不过,由于稍后解释的原因,你可能会希望写个单元测试来确认这些链接是否正确使用了 RouterLink
指令。
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.
要想验证这些链接,你不必用 Router
进行导航,也不必使用 <router-outlet>
来指出 Router
应该把路由目标组件插入到什么地方。
To validate the links, you don't need the Router
to navigate and you don't need the <router-outlet>
to mark where the Router
inserts routed components.
而 BannerComponent
和 WelcomeComponent
(写作 <app-banner>
和 <app-welcome>
)也同样风马牛不相及。
The BannerComponent
and WelcomeComponent
(indicated by <app-banner>
and <app-welcome>
) are also irrelevant.
然而,任何测试,只要能在 DOM 中创建 AppComponent
,也就同样能创建这三个组件的实例。如果要创建它们,你就要配置 TestBed
。
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.
如果你忘了声明它们,Angular 编译器就无法在 AppComponent
模板中识别出 <app-banner>
、<app-welcome>
和 <router-outlet>
标记,并抛出一个错误。
If you neglect to declare them, the Angular compiler won't recognize the <app-banner>
, <app-welcome>
, and <router-outlet>
tags in the AppComponent
template and will throw an error.
如果你声明的这些都是真实的组件,那么也同样要声明它们的嵌套组件,并要为这棵组件树中的任何组件提供要注入的所有服务。
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.
对不需要的组件提供桩(stub)
Stubbing unneeded components
这项技术中,你要为那些在测试中无关紧要的组件或指令创建和声明一些测试桩。
In the first technique, you create and declare stub versions of the components and directive that play little or no role in the tests.
@Component({selector: 'app-banner', template: ''})
class BannerStubComponent {}
@Component({selector: 'router-outlet', template: ''})
class RouterOutletStubComponent { }
@Component({selector: 'app-welcome', template: ''})
class WelcomeStubComponent {}
这些测试桩的选择器要和其对应的真实组件一致,但其模板和类是空的。
The stub selectors match the selectors for the corresponding real components. But their templates and classes are empty.
然后在 TestBed
的配置中那些真正有用的组件、指令、管道之后声明它们。
Then declare them in the TestBed
configuration next to the components, directives, and pipes that need to be real.
TestBed.configureTestingModule({
declarations: [
AppComponent,
RouterLinkDirectiveStub,
BannerStubComponent,
RouterOutletStubComponent,
WelcomeStubComponent
]
})
AppComponent
是该测试的主角,因此当然要用它的真实版本。
The AppComponent
is the test subject, so of course you declare the real version.
而 RouterLinkDirectiveStub
(稍后讲解)是一个真实的 RouterLink
的测试版,它能帮你对链接进行测试。
The RouterLinkDirectiveStub
, described later, is a test version of the real RouterLink
that helps with the link tests.
其它都是测试桩。
The rest are stubs.
NO_ERRORS_SCHEMA
第二种办法就是把 NO_ERRORS_SCHEMA
添加到 TestBed.schemas
的元数据中。
In the second approach, add NO_ERRORS_SCHEMA
to the TestBed.schemas
metadata.
TestBed.configureTestingModule({
declarations: [
AppComponent,
RouterLinkDirectiveStub
],
schemas: [ NO_ERRORS_SCHEMA ]
})
NO_ERRORS_SCHEMA
会要求 Angular 编译器忽略不认识的那些元素和属性。
The NO_ERRORS_SCHEMA
tells the Angular compiler to ignore unrecognized elements and attributes.
编译器将会识别出 <app-root>
元素和 RouterLink
属性,因为你在 TestBed
的配置中声明了相应的 AppComponent
和 RouterLinkDirectiveStub
。
The compiler will recognize the <app-root>
element and the routerLink
attribute because you declared a corresponding AppComponent
and RouterLinkDirectiveStub
in the TestBed
configuration.
但编译器在遇到 <app-banner>
、<app-welcome>
或 <router-outlet>
时不会报错。 它只会把它们渲染成空白标签,而浏览器会忽略这些标签。
But the compiler won't throw an error when it encounters <app-banner>
, <app-welcome>
, or <router-outlet>
. 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.
NO_ERRORS_SCHEMA
方法在这两者中比较简单,但也不要过度使用它。
The NO_ERRORS_SCHEMA
approach is the easier of the two but don't overuse it.
NO_ERRORS_SCHEMA
还会阻止编译器告诉你因为的疏忽或拼写错误而缺失的组件和属性。 你如果人工找出这些 bug 可能要浪费几个小时,但编译器可以立即捕获它们。
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.
桩组件方式还有其它优点。 虽然这个例子中的桩是空的,但你如果想要和它们用某种形式互动,也可以给它们一些裁剪过的模板和类。
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.
TestBed.configureTestingModule({
declarations: [
AppComponent,
BannerStubComponent,
RouterLinkDirectiveStub
],
schemas: [ NO_ERRORS_SCHEMA ]
})
Angular 编译器会为 <app-banner>
元素创建 BannerComponentStub
,并把 RouterLinkStubDirective
应用到带有 routerLink
属性的链接上,不过它会忽略 <app-welcome>
和 <router-outlet>
标签。
The Angular compiler creates the BannerComponentStub
for the <app-banner>
element and applies the RouterLinkStubDirective
to the anchors with the routerLink
attribute, but it ignores the <app-welcome>
and <router-outlet>
tags.
带有 RouterLink
的组件
Components with RouterLink
真实的 RouterLinkDirective
太复杂了,而且与 RouterModule
中的其它组件和指令有着千丝万缕的联系。 要在准备阶段 Mock 它以及在测试中使用它具有一定的挑战性。
The real RouterLinkDirective
is quite complicated and entangled with other components and directives of the RouterModule
. It requires challenging setup to mock and use in tests.
这段范例代码中的 RouterLinkDirectiveStub
用一个代用品替换了真实的指令,这个代用品用来验证 AppComponent
中所用链接的类型。
The RouterLinkDirectiveStub
in this sample code replaces the real directive with an alternative version designed to validate the kind of anchor tag wiring seen in the AppComponent
template.
@Directive({
selector: '[routerLink]',
host: { '(click)': 'onClick()' }
})
export class RouterLinkDirectiveStub {
@Input('routerLink') linkParams: any;
navigatedTo: any = null;
onClick() {
this.navigatedTo = this.linkParams;
}
}
这个 URL 被绑定到了 [routerLink]
属性,它的值流入了该指令的 linkParams
属性。
The URL bound to the [routerLink]
attribute flows in to the directive's linkParams
property.
它的元数据中的 host
属性把宿主元素(即 AppComponent
中的 <a>
元素)的 click
事件关联到了这个桩指令的 onClick
方法。
The host
metadata property wires the click event of the host element (the <a>
anchor elements in AppComponent
) to the stub directive's onClick
method.
点击这个链接应该触发 onClick()
方法,其中会设置该桩指令中的警示器属性 navigatedTo
。 测试中检查 navigatedTo
以确认点击该链接确实如预期的那样根据路由定义设置了该属性。
Clicking the anchor should trigger the onClick()
method, which sets the stub's telltale navigatedTo
property. Tests inspect navigatedTo
to confirm that clicking the anchor set the expected route definition.
路由器的配置是否正确和是否能按照那些路由定义进行导航,是测试中一组独立的问题。
Whether the router is configured properly to navigate with that route definition is a question for a separate set of tests.
By.directive
与注入的指令
By.directive and injected directives
再一步配置触发了数据绑定的初始化,获取导航链接的引用:
A little more setup triggers the initial data binding and gets references to the navigation links:
beforeEach(() => {
fixture.detectChanges(); // trigger initial data binding
// find DebugElements with an attached RouterLinkStubDirective
linkDes = fixture.debugElement
.queryAll(By.directive(RouterLinkDirectiveStub));
// get attached link directive instances
// using each DebugElement's injector
routerLinks = linkDes.map(de => de.injector.get(RouterLinkDirectiveStub));
});
有三点特别重要:
Three points of special interest:
你可以使用
By.directive
来定位一个带附属指令的链接元素。You can locate the anchor elements with an attached directive using
By.directive
.该查询返回包含了匹配元素的
DebugElement
包装器。The query returns
DebugElement
wrappers around the matching elements.每个
DebugElement
都会导出该元素中的一个依赖注入器,其中带有指定的指令实例。Each
DebugElement
exposes a dependency injector with the specific instance of the directive attached to that element.
AppComponent
中要验证的链接如下:
The AppComponent
links to validate are as follows:
<nav>
<a routerLink="/dashboard">Dashboard</a>
<a routerLink="/heroes">Heroes</a>
<a routerLink="/about">About</a>
</nav>
下面这些测试用来确认那些链接是否如预期般连接到了 RouterLink
指令中:
Here are some tests that confirm those links are wired to the routerLink
directives as expected:
it('can get RouterLinks from template', () => {
expect(routerLinks.length).toBe(3, 'should have 3 routerLinks');
expect(routerLinks[0].linkParams).toBe('/dashboard');
expect(routerLinks[1].linkParams).toBe('/heroes');
expect(routerLinks[2].linkParams).toBe('/about');
});
it('can click Heroes link in template', () => {
const heroesLinkDe = linkDes[1]; // heroes link DebugElement
const heroesLink = routerLinks[1]; // heroes link directive
expect(heroesLink.navigatedTo).toBeNull('should not have navigated yet');
heroesLinkDe.triggerEventHandler('click', null);
fixture.detectChanges();
expect(heroesLink.navigatedTo).toBe('/heroes');
});
其实这个例子中的“click”测试误入歧途了。 它测试的重点其实是 RouterLinkDirectiveStub
,而不是该组件。 这是写桩指令时常见的错误。
The "click" test in this example is misleading. It tests the RouterLinkDirectiveStub
rather than the component. This is a common failing of directive stubs.
在本章中,它有存在的必要。 它演示了如何在不涉及完整路由器机制的情况下,如何找到 RouterLink
元素、点击它并检查结果。 要测试更复杂的组件,你可能需要具备这样的能力,能改变视图和重新计算参数,或者当用户点击链接时,有能力重新安排导航选项。
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.
这些测试有什么优点?
What good are these tests?
用 RouterLink
的桩指令进行测试可以确认带有链接和 outlet 的组件的设置的正确性,确认组件有应该有的链接,确认它们都指向了正确的方向。 这些测试程序不关心用户点击链接时,也不关心应用是否会成功的导航到目标组件。
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.
对于这些有限的测试目标,使用 RouterLink 桩指令和 RouterOutlet 桩组件 是最佳选择。 依靠真正的路由器会让它们很脆弱。 它们可能因为与组件无关的原因而失败。 例如,一个导航守卫可能防止没有授权的用户访问 HeroListComponent
。 这并不是 AppComponent
的过错,并且无论该组件怎么改变都无法修复这个失败的测试程序。
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.
一组不同的测试程序可以探索当存在影响守卫的条件时(比如用户是否已认证和授权),该应用是否如期望般导航。
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.
未来对本章的更新将介绍如何使用 RouterTestingModule
来编写这样的测试程序。
A future guide update will explain how to write such tests with the RouterTestingModule
.
使用页面(page)对象
Use a page object
HeroDetailComponent
是带有标题、两个英雄字段和两个按钮的简单视图。
The HeroDetailComponent
is a simple view with a title, two hero fields, and two buttons.
![HeroDetailComponent in action](generated/images/guide/testing/hero-detail.component.png)
但即使是这么简单的表单,其模板中也涉及到不少复杂性。
But there's plenty of template complexity even in this simple form.
<div *ngIf="hero">
<h2><span>{{hero.name | titlecase}}</span> Details</h2>
<div>
<label>id: </label>{{hero.id}}</div>
<div>
<label for="name">name: </label>
<input id="name" [(ngModel)]="hero.name" placeholder="name" />
</div>
<button (click)="save()">Save</button>
<button (click)="cancel()">Cancel</button>
</div>
这些供练习用的组件需要 ……
Tests that exercise the component need ...
等获取到英雄之后才能让元素出现在 DOM 中。
to wait until a hero arrives before elements appear in the DOM.
一个对标题文本的引用。
a reference to the title text.
一个对 name 输入框的引用,以便对它进行探查和修改。
a reference to the name input box to inspect and set it.
引用两个按钮,以便点击它们。
references to the two buttons so they can click them.
为组件和路由器的方法安插间谍。
spies for some of the component and router methods.
即使是像这样一个很小的表单,也能产生令人疯狂的错综复杂的条件设置和 CSS 元素选择。
Even a small form such as this one can produce a mess of tortured conditional setup and CSS element selection.
可以使用 Page
类来征服这种复杂性。Page
类可以处理对组件属性的访问,并对设置这些属性的逻辑进行封装。
Tame the complexity with a Page
class that handles access to component properties and encapsulates the logic that sets them.
下面是一个供 hero-detail.component.spec.ts
使用的 Page
类
Here is such a Page
class for the hero-detail.component.spec.ts
class Page {
// getter properties wait to query the DOM until called.
get buttons() { return this.queryAll<HTMLButtonElement>('button'); }
get saveBtn() { return this.buttons[0]; }
get cancelBtn() { return this.buttons[1]; }
get nameDisplay() { return this.query<HTMLElement>('span'); }
get nameInput() { return this.query<HTMLInputElement>('input'); }
gotoListSpy: jasmine.Spy;
navigateSpy: jasmine.Spy;
constructor(fixture: ComponentFixture<HeroDetailComponent>) {
// get the navigate spy from the injected router spy object
const routerSpy = <any> fixture.debugElement.injector.get(Router);
this.navigateSpy = routerSpy.navigate;
// spy on component's `gotoList()` method
const component = fixture.componentInstance;
this.gotoListSpy = spyOn(component, 'gotoList').and.callThrough();
}
//// query helpers ////
private query<T>(selector: string): T {
return fixture.nativeElement.querySelector(selector);
}
private queryAll<T>(selector: string): T[] {
return fixture.nativeElement.querySelectorAll(selector);
}
}
现在,用来操作和检查组件的重要钩子都被井然有序的组织起来了,可以通过 page
实例来使用它们。
Now the important hooks for component manipulation and inspection are neatly organized and accessible from an instance of Page
.
createComponent
方法会创建一个 page
对象,并在 hero
到来时自动填补空白。
A createComponent
method creates a page
object and fills in the blanks once the hero
arrives.
/** Create the HeroDetailComponent, initialize it, set test variables */
function createComponent() {
fixture = TestBed.createComponent(HeroDetailComponent);
component = fixture.componentInstance;
page = new Page(fixture);
// 1st change detection triggers ngOnInit which gets a hero
fixture.detectChanges();
return fixture.whenStable().then(() => {
// 2nd change detection displays the async-fetched hero
fixture.detectChanges();
});
}
前面小节中的 HeroDetailComponent
测试示范了如何 createComponent
,而 page
让这些测试保持简短而富有表达力。 而且还不用分心:不用等待承诺被解析,不必在 DOM 中找出元素的值才能进行比较。
The HeroDetailComponent tests in an earlier 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.
还有更多的 HeroDetailComponent
测试可以证明这一点。
Here are a few more HeroDetailComponent
tests to reinforce the point.
it('should display that hero\'s name', () => {
expect(page.nameDisplay.textContent).toBe(expectedHero.name);
});
it('should navigate when click cancel', () => {
click(page.cancelBtn);
expect(page.navigateSpy.calls.any()).toBe(true, 'router.navigate called');
});
it('should save when click save but not navigate immediately', () => {
// Get service injected into component and spy on its`saveHero` method.
// It delegates to fake `HeroService.updateHero` which delivers a safe test result.
const hds = fixture.debugElement.injector.get(HeroDetailService);
const saveSpy = spyOn(hds, 'saveHero').and.callThrough();
click(page.saveBtn);
expect(saveSpy.calls.any()).toBe(true, 'HeroDetailService.save called');
expect(page.navigateSpy.calls.any()).toBe(false, 'router.navigate not called');
});
it('should navigate when click save and save resolves', fakeAsync(() => {
click(page.saveBtn);
tick(); // wait for async save to complete
expect(page.navigateSpy.calls.any()).toBe(true, 'router.navigate called');
}));
it('should convert hero name to Title Case', () => {
// get the name's input and display elements from the DOM
const hostElement = fixture.nativeElement;
const nameInput: HTMLInputElement = hostElement.querySelector('input');
const nameDisplay: HTMLElement = hostElement.querySelector('span');
// simulate user entering a new name into the input box
nameInput.value = 'quick BROWN fOx';
// dispatch a DOM event so that Angular learns of input value change.
nameInput.dispatchEvent(newEvent('input'));
// Tell Angular to update the display binding through the title pipe
fixture.detectChanges();
expect(nameDisplay.textContent).toBe('Quick Brown Fox');
});
调用 compileComponents()
Calling compileComponents()
如果你只想使用 CLI 的 ng test
命令来运行测试,那么可以忽略这一节。
You can ignore this section if you only run tests with the CLI ng test
command because the CLI compiles the application before running the tests.
如果你在非 CLI 环境中运行测试,这些测试可能会报错,错误信息如下:
If you run tests in a non-CLI environment, the tests may fail with a message like this one:
Error: This test module uses the component BannerComponent
which is using a "templateUrl" or "styleUrls", but they were never compiled.
Please call "TestBed.compileComponents" before your test.
问题的根源在于这个测试中至少有一个组件引用了外部模板或外部 CSS 文件,就像下面这个版本的 BannerComponent
所示:
The root of the problem is at least one of the components involved in the test specifies an external template or CSS file as the following version of the BannerComponent
does.
import { Component } from '@angular/core';
@Component({
selector: 'app-banner',
templateUrl: './banner-external.component.html',
styleUrls: ['./banner-external.component.css']
})
export class BannerComponent {
title = 'Test Tour of Heroes';
}
当 TestBed
视图创建组件时,这个测试失败了:
The test fails when the TestBed
tries to create the component.
beforeEach(() => {
TestBed.configureTestingModule({
declarations: [ BannerComponent ],
});
fixture = TestBed.createComponent(BannerComponent);
});
回想一下,这个应用从未编译过。 所以当你调用 createComponent()
的时候,TestBed
就会进行隐式编译。
Recall that the app hasn't been compiled. So when you call createComponent()
, the TestBed
compiles implicitly.
当它的源码都在内存中的时候,这样做没问题。 不过 BannerComponent
需要一些外部文件,编译时必须从文件系统中读取它,而这是一个天生的异步操作。
That's not a problem when the source code is in memory. But the BannerComponent
requires external files that the compile must read from the file system, an inherently asynchronous operation.
如果 TestBed
继续执行,这些测试就会继续运行,并在编译器完成这些异步工作之前导致莫名其妙的失败。
If the TestBed
were allowed to continue, the tests would run and fail mysteriously before the compiler could finished.
这些错误信息告诉你要使用 compileComponents()
进行显式的编译。
The preemptive error message tells you to compile explicitly with compileComponents()
.
compileComponents()
是异步的
compileComponents() is async
你必须在异步测试函数中调用 compileComponents()
。
You must call compileComponents()
within an asynchronous test function.
如果你忘了把测试函数标为异步的(比如忘了像稍后的代码中那样使用 async()
),就会看到下列错误。
If you neglect to make the test function async (e.g., forget to use async()
as described below), you'll see this error message
Error: ViewDestroyedError: Attempt to use a destroyed view
典型的做法是把准备逻辑拆成两个独立的 beforeEach()
函数:
A typical approach is to divide the setup logic into two separate beforeEach()
functions:
异步的
beforeEach()
负责编译组件An async
beforeEach()
that compiles the components同步的
beforeEach()
负责执行其余的准备代码。A synchronous
beforeEach()
that performs the remaining setup.
要想使用这种模式,就要和其它符号一起从测试库中导入 async()
辅助函数。
To follow this pattern, import the async()
helper with the other testing symbols.
import { async, ComponentFixture, TestBed } from '@angular/core/testing';
异步的 beforeEach
The async beforeEach
像下面这样编写第一个异步的 beforeEach
。
Write the first async beforeEach
like this.
beforeEach(async(() => {
TestBed.configureTestingModule({
declarations: [ BannerComponent ],
})
.compileComponents(); // compile template and css
}));
async()
辅助函数接受一个无参函数,其内容是环境准备代码。
The async()
helper function takes a parameterless function with the body of the setup.
TestBed.configureTestingModule()
方法返回 TestBed
类,所以你可以链式调用其它 TestBed
中的静态方法,比如 compileComponents()
。
The TestBed.configureTestingModule()
method returns the TestBed
class so you can chain calls to other TestBed
static methods such as compileComponents()
.
在这个例子中,BannerComponent
是仅有的待编译组件。 其它例子中可能会使用多个组件来配置测试模块,并且可能引入某些具有其它组件的应用模块。 它们中的任何一个都可能需要外部文件。
In this example, the BannerComponent
is the only component to compile. Other examples configure the testing module with multiple components and may import application modules that hold yet more components. Any of them could be require external files.
TestBed.compileComponents
方法会异步编译测试模块中配置过的所有组件。
The TestBed.compileComponents
method asynchronously compiles all components configured in the testing module.
在调用了 compileComponents()
之后就不能再重新配置 TestBed
了。
Do not re-configure the TestBed
after calling compileComponents()
.
调用 compileComponents()
会关闭当前的 TestBed
实例,不再允许进行配置。 你不能再调用任何 TestBed
中的配置方法,既不能调 configureTestingModule()
,也不能调用任何 override...
方法。如果你试图这么做,TestBed
就会抛出错误。
Calling compileComponents()
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.
确保 compileComponents()
是调用 TestBed.createComponent()
之前的最后一步。
Make compileComponents()
the last step before calling TestBed.createComponent()
.
同步的 beforeEach
The synchronous beforeEach
第二个同步 beforeEach()
的例子包含剩下的准备步骤, 包括创建组件和查询那些要检查的元素。
The second, synchronous beforeEach()
contains the remaining setup steps, which include creating the component and querying for elements to inspect.
beforeEach(() => {
fixture = TestBed.createComponent(BannerComponent);
component = fixture.componentInstance; // BannerComponent test instance
h1 = fixture.nativeElement.querySelector('h1');
});
测试运行器(runner)会先等待第一个异步 beforeEach
函数执行完再调用第二个。
You can count on the test runner to wait for the first asynchronous beforeEach
to finish before calling the second.
整理过的准备代码
Consolidated setup
你可以把这两个 beforeEach()
函数重整成一个异步的 beforeEach()
。
You can consolidate the two beforeEach()
functions into a single, async beforeEach()
.
compileComponents()
方法返回一个承诺,所以你可以通过把同步代码移到 then(...)
回调中, 以便在编译完成之后 执行那些同步准备任务。
The compileComponents()
method returns a promise so you can perform the synchronous setup tasks after compilation by moving the synchronous code into a then(...)
callback.
beforeEach(async(() => {
TestBed.configureTestingModule({
declarations: [ BannerComponent ],
})
.compileComponents()
.then(() => {
fixture = TestBed.createComponent(BannerComponent);
component = fixture.componentInstance;
h1 = fixture.nativeElement.querySelector('h1');
});
}));
compileComponents()
是无害的
compileComponents() is harmless
在不需要 compileComponents()
的时候调用它也不会有害处。
There's no harm in calling compileComponents()
when it's not required.
虽然在运行 ng test
时永远都不需要调用 compileComponents()
,但 CLI 生成的组件测试文件还是会调用它。
The component test file generated by the CLI calls compileComponents()
even though it is never required when running ng test
.
但这篇指南中的这些测试只会在必要时才调用 compileComponents
。
The tests in this guide only call compileComponents
when necessary.
准备模块的 imports
Setup with module imports
此前的组件测试程序使用了一些 declarations
来配置模块,就像这样:
Earlier component tests configured the testing module with a few declarations
like this:
TestBed.configureTestingModule({
declarations: [ DashboardHeroComponent ]
})
DashbaordComponent
非常简单。它不需要帮助。 但是更加复杂的组件通常依赖其它组件、指令、管道和提供商, 所以这些必须也被添加到测试模块中。
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.
幸运的是,TestBed.configureTestingModule
参数与传入 @NgModule
装饰器的元数据一样,也就是所你也可以指定 providers
和 imports
.
Fortunately, the TestBed.configureTestingModule
parameter parallels the metadata passed to the @NgModule
decorator which means you can also specify providers
and imports
.
虽然 HeroDetailComponent
很小,结构也很简单,但是它需要很多帮助。 除了从默认测试模块 CommonModule
中获得的支持,它还需要:
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:
FormsModule
里的NgModel
和其它,来进行双向数据绑定NgModel
and friends in theFormsModule
to enable two-way data binding.shared
目录里的TitleCasePipe
The
TitleCasePipe
from theshared
folder.一些路由器服务(测试程序将 stub 伪造它们)
Router services (which these tests are stubbing).
英雄数据访问服务(同样被 stub 伪造了)
Hero data access services (also stubbed).
一种方法是从各个部分配置测试模块,就像这样:
One approach is to configure the testing module from the individual pieces as in this example:
beforeEach(async(() => {
const routerSpy = createRouterSpy();
TestBed.configureTestingModule({
imports: [ FormsModule ],
declarations: [ HeroDetailComponent, TitleCasePipe ],
providers: [
{ provide: ActivatedRoute, useValue: activatedRoute },
{ provide: HeroService, useClass: TestHeroService },
{ provide: Router, useValue: routerSpy},
]
})
.compileComponents();
}));
注意,beforeEach()
是异步的,它调用 TestBed.compileComponents
是因为 HeroDetailComponent
有外部模板和 CSS 文件。
Notice that the beforeEach()
is asynchronous and calls TestBed.compileComponents
because the HeroDetailComponent
has an external template and css file.
如前面的调用 compileComponents()
中所解释的那样,这些测试可以运行在非 CLI 环境下,那里 Angular 并不会在浏览器中编译它们。
As explained in Calling compileComponents() above, these tests could be run in a non-CLI environment where Angular would have to compile them in the browser.
导入共享模块
Import a shared module
因为很多应用组件都需要 FormsModule
和 TitleCasePipe
,所以开发者创建了 SharedModule
来把它们及其它常用的部分组合在一起。
Because many app components need the FormsModule
and the TitleCasePipe
, the developer created a SharedModule
to combine these and other frequently requested parts.
这些测试配置也可以使用 SharedModule
,如下所示:
The test configuration can use the SharedModule
too as seen in this alternative setup:
beforeEach(async(() => {
const routerSpy = createRouterSpy();
TestBed.configureTestingModule({
imports: [ SharedModule ],
declarations: [ HeroDetailComponent ],
providers: [
{ provide: ActivatedRoute, useValue: activatedRoute },
{ provide: HeroService, useClass: TestHeroService },
{ provide: Router, useValue: routerSpy},
]
})
.compileComponents();
}));
它的导入声明少一些(未显示),稍微干净一些,小一些。
It's a bit tighter and smaller, with fewer import statements (not shown).
导入特性模块
Import a feature module
HeroDetailComponent
是 HeroModule
这个特性模块的一部分,它聚合了更多相互依赖的片段,包括 SharedModule
。 试试下面这个导入了 HeroModule
的测试配置:
The HeroDetailComponent
is part of the HeroModule
Feature Module that aggregates more of the interdependent pieces including the SharedModule
. Try a test configuration that imports the HeroModule
like this one:
beforeEach(async(() => {
const routerSpy = createRouterSpy();
TestBed.configureTestingModule({
imports: [ HeroModule ],
providers: [
{ provide: ActivatedRoute, useValue: activatedRoute },
{ provide: HeroService, useClass: TestHeroService },
{ provide: Router, useValue: routerSpy},
]
})
.compileComponents();
}));
这样特别清爽。只有 providers
里面的测试替身被保留。连 HeroDetailComponent
声明都消失了。
That's really crisp. Only the test doubles in the providers
remain. Even the HeroDetailComponent
declaration is gone.
事实上,如果你试图声明它,Angular 就会抛出一个错误,因为 HeroDetailComponent
同时声明在了 HeroModule
和 TestBed
创建的 DynamicTestModule
中。
In fact, if you try to declare it, Angular will throw an error because HeroDetailComponent
is declared in both the HeroModule
and the DynamicTestModule
created by the TestBed
.
如果模块中有很多共同依赖,并且该模块很小(这也是特性模块的应有形态),那么直接导入组件的特性模块可以成为配置这些测试的简易方式。
Importing the component's feature module can be the easiest way to configure tests when there are many mutual dependencies within the module and the module is small, as feature modules tend to be.
改写组件的服务提供商
Override component providers
HeroDetailComponent
提供自己的 HeroDetailService
服务。
The HeroDetailComponent
provides its own HeroDetailService
.
@Component({
selector: 'app-hero-detail',
templateUrl: './hero-detail.component.html',
styleUrls: ['./hero-detail.component.css' ],
providers: [ HeroDetailService ]
})
export class HeroDetailComponent implements OnInit {
constructor(
private heroDetailService: HeroDetailService,
private route: ActivatedRoute,
private router: Router) {
}
}
在 TestBed.configureTestingModule
的 providers
中 stub 伪造组件的 HeroDetailService
是不可行的。 这些是测试模块的提供商,而非组件的。组件级别的供应商应该在fixture 级别准备的依赖注入器。
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.
Angular 会使用自己的注入器来创建这些组件,这个注入器是夹具的注入器的子注入器。 它使用这个子注入器注册了该组件服务提供商(这里是 HeroDetailService
)。
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.
测试没办法从测试夹具的注入器中获取子注入器中的服务,而 TestBed.configureTestingModule
也没法配置它们。
A test cannot get to child injector services from the fixture injector. And TestBed.configureTestingModule
can't configure them either.
Angular 始终都在创建真实 HeroDetailService
的实例。
Angular has been creating new instances of the real HeroDetailService
all along!
如果 HeroDetailService
向远程服务器发出自己的 XHR 请求,这些测试可能会失败或者超时。 这个远程服务器可能根本不存在。
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
将远程数据访问的责任交给了注入进来的 HeroService
。
Fortunately, the HeroDetailService
delegates responsibility for remote data access to an injected HeroService
.
@Injectable()
export class HeroDetailService {
constructor(private heroService: HeroService) { }
/* . . . */
}
前面的测试配置使用 TestHeroService
替换了真实的 HeroService
,它拦截了发往服务器的请求,并伪造了服务器的响应。
The previous test configuration replaces the real HeroService
with a TestHeroService
that intercepts server requests and fakes their responses.
如果你没有这么幸运怎么办?如果伪造 HeroService
很难怎么办?如果 HeroDetailService
自己发出服务器请求怎么办?
What if you aren't so lucky. What if faking the HeroService
is hard? What if HeroDetailService
makes its own server requests?
TestBed.overrideComponent
方法可以将组件的 providers
替换为容易管理的测试替身,参见下面的变体准备代码:
The TestBed.overrideComponent
method can replace the component's providers
with easy-to-manage test doubles as seen in the following setup variation:
beforeEach(async(() => {
const routerSpy = createRouterSpy();
TestBed.configureTestingModule({
imports: [ HeroModule ],
providers: [
{ provide: ActivatedRoute, useValue: activatedRoute },
{ provide: Router, useValue: routerSpy},
]
})
// Override component's own provider
.overrideComponent(HeroDetailComponent, {
set: {
providers: [
{ provide: HeroDetailService, useClass: HeroDetailServiceSpy }
]
}
})
.compileComponents();
}));
注意,TestBed.configureTestingModule
不再提供(伪造的)HeroService
,因为并不需要。
Notice that TestBed.configureTestingModule
no longer provides a (fake) HeroService
because it's not needed.
overrideComponent
方法
The overrideComponent method
注意这个 overrideComponent
方法。
Focus on the overrideComponent
method.
.overrideComponent(HeroDetailComponent, {
set: {
providers: [
{ provide: HeroDetailService, useClass: HeroDetailServiceSpy }
]
}
})
它接受两个参数:要改写的组件类型(HeroDetailComponent
),以及用于改写的元数据对象。 用于改写的元数据对象是一个泛型,其定义如下:
It takes two arguments: the component type to override (HeroDetailComponent
) and an override metadata object. The override metadata object is a generic defined as follows:
type MetadataOverride = {
add?: Partial;
remove?: Partial;
set?: Partial;
};
元数据重载对象可以添加和删除元数据属性的项目,也可以彻底重设这些属性。 这个例子重新设置了组件的 providers
元数据。
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.
这个类型参数 T
就是你传给 @Component
装饰器的元数据:
The type parameter, T
, is the kind of metadata you'd pass to the @Component
decorator:
selector?: string;
template?: string;
templateUrl?: string;
providers?: any[];
...
提供 间谍桩
(HeroDetailServiceSpy
)
Provide a spy stub (HeroDetailServiceSpy)
这个例子把组件的 providers
数组完全替换成了一个包含 HeroDetailServiceSpy
的新数组。
This example completely replaces the component's providers
array with a new array containing a HeroDetailServiceSpy
.
HeroDetailServiceSpy
是实际 HeroDetailService
服务的桩版本,它伪造了该服务的所有必要特性。 但它既不需要注入也不会委托给低层的 HeroService
服务,因此不用为 HeroService
提供测试替身。
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.
通过对该服务的方法进行刺探,HeroDetailComponent
的关联测试将会对 HeroDetailService
是否被调用过进行断言。 因此,这个桩类会把它的方法实现为刺探方法:
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:
class HeroDetailServiceSpy {
testHero: Hero = {id: 42, name: 'Test Hero' };
/* emit cloned test hero */
getHero = jasmine.createSpy('getHero').and.callFake(
() => asyncData(Object.assign({}, this.testHero))
);
/* emit clone of test hero, with changes merged in */
saveHero = jasmine.createSpy('saveHero').and.callFake(
(hero: Hero) => asyncData(Object.assign(this.testHero, hero))
);
}
改写测试
The override tests
现在,测试程序可以通过操控这个 spy-stub 的 testHero
,直接控制组件的英雄,并确认那个服务方法被调用过。
Now the tests can control the component's hero directly by manipulating the spy-stub's testHero
and confirm that service methods were called.
let hdsSpy: HeroDetailServiceSpy;
beforeEach(async(() => {
createComponent();
// get the component's injected HeroDetailServiceSpy
hdsSpy = fixture.debugElement.injector.get(HeroDetailService) as any;
}));
it('should have called `getHero`', () => {
expect(hdsSpy.getHero.calls.count()).toBe(1, 'getHero called once');
});
it('should display stub hero\'s name', () => {
expect(page.nameDisplay.textContent).toBe(hdsSpy.testHero.name);
});
it('should save stub hero change', fakeAsync(() => {
const origName = hdsSpy.testHero.name;
const newName = 'New Name';
page.nameInput.value = newName;
page.nameInput.dispatchEvent(newEvent('input')); // tell Angular
expect(component.hero.name).toBe(newName, 'component hero has new name');
expect(hdsSpy.testHero.name).toBe(origName, 'service hero unchanged before save');
click(page.saveBtn);
expect(hdsSpy.saveHero.calls.count()).toBe(1, 'saveHero called once');
tick(); // wait for async save to complete
expect(hdsSpy.testHero.name).toBe(newName, 'service hero has new name after save');
expect(page.navigateSpy.calls.any()).toBe(true, 'router.navigate called');
}));
更多的改写
More overrides
TestBed.overrideComponent
方法可以在相同或不同的组件中被反复调用。 TestBed
还提供了类似的 overrideDirective
、overrideModule
和 overridePipe
方法,用来深入并重载这些其它类的部件。
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.
自己探索这些选项和组合。
Explore the options and combinations on your own.
属性型指令的测试
Attribute Directive Testing
属性指令修改元素、组件和其它指令的行为。正如它们的名字所示,它们是作为宿主元素的属性来被使用的。
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.
本例子应用的 HighlightDirective
使用数据绑定的颜色或者默认颜色来设置元素的背景色。 它同时设置元素的 customProperty
属性为 true
,这里仅仅是为了显示它能这么做而已,并无其它原因。
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.
import { Directive, ElementRef, Input, OnChanges } from '@angular/core';
@Directive({ selector: '[highlight]' })
/** Set backgroundColor for the attached element to highlight color
* and set the element's customProperty to true */
export class HighlightDirective implements OnChanges {
defaultColor = 'rgb(211, 211, 211)'; // lightgray
@Input('highlight') bgColor: string;
constructor(private el: ElementRef) {
el.nativeElement.style.customProperty = true;
}
ngOnChanges() {
this.el.nativeElement.style.backgroundColor = this.bgColor || this.defaultColor;
}
}
它的使用贯穿整个应用,也许最简单的使用在 AboutComponent
里:
It's used throughout the application, perhaps most simply in the AboutComponent
:
import { Component } from '@angular/core';
@Component({
template: `
<h2 highlight="skyblue">About</h2>
<h3>Quote of the day:</h3>
<twain-quote></twain-quote>
`
})
export class AboutComponent { }
要想在 AboutComponent
中测试 HighlightDirective
的具体用法,只要使用在“浅层测试”部分用过的技术即可。
Testing the specific use of the HighlightDirective
within the AboutComponent
requires only the techniques explored above (in particular the "Shallow test" approach).
beforeEach(() => {
fixture = TestBed.configureTestingModule({
declarations: [ AboutComponent, HighlightDirective],
schemas: [ NO_ERRORS_SCHEMA ]
})
.createComponent(AboutComponent);
fixture.detectChanges(); // initial binding
});
it('should have skyblue <h2>', () => {
const h2: HTMLElement = fixture.nativeElement.querySelector('h2');
const bgColor = h2.style.backgroundColor;
expect(bgColor).toBe('skyblue');
});
但是,测试单一的用例一般无法探索该指令的全部能力。 查找和测试所有使用该指令的组件非常繁琐和脆弱,并且通常无法覆盖所有组件。
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.
只针对类的测试可能很有用, 但是像这个一样的属性型指令肯定要操纵 DOM。 隔离出的单元测试不能接触 DOM,因此也就没办法证明该指令的有效性。
Class-only tests might be helpful, but attribute directives like this one tend to manipulate the DOM. Isolated unit tests don't touch the DOM and, therefore, do not inspire confidence in the directive's efficacy.
更好的方法是创建一个能展示该指令所有用法的人造测试组件。
A better solution is to create an artificial test component that demonstrates all ways to apply the directive.
@Component({
template: `
<h2 highlight="yellow">Something Yellow</h2>
<h2 highlight>The Default (Gray)</h2>
<h2>No Highlight</h2>
<input #box [highlight]="box.value" value="cyan"/>`
})
class TestComponent { }
![HighlightDirective spec in action](generated/images/guide/testing/highlight-directive-spec.png)
<input>
用例将 HighlightDirective
绑定到输入框里输入的颜色名字。 初始只是单词“cyan”,所以输入框的背景色应该是 cyan。
The <input>
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.
下面是一些该组件的测试程序:
Here are some tests of this component:
- beforeEach(() => {
- fixture = TestBed.configureTestingModule({
- declarations: [ HighlightDirective, TestComponent ]
- })
- .createComponent(TestComponent);
-
- fixture.detectChanges(); // initial binding
-
- // all elements with an attached HighlightDirective
- des = fixture.debugElement.queryAll(By.directive(HighlightDirective));
-
- // the h2 without the HighlightDirective
- bareH2 = fixture.debugElement.query(By.css('h2:not([highlight])'));
- });
-
- // color tests
- it('should have three highlighted elements', () => {
- expect(des.length).toBe(3);
- });
-
- it('should color 1st <h2> background "yellow"', () => {
- const bgColor = des[0].nativeElement.style.backgroundColor;
- expect(bgColor).toBe('yellow');
- });
-
- it('should color 2nd <h2> background w/ default color', () => {
- const dir = des[1].injector.get(HighlightDirective) as HighlightDirective;
- const bgColor = des[1].nativeElement.style.backgroundColor;
- expect(bgColor).toBe(dir.defaultColor);
- });
-
- it('should bind <input> background to value color', () => {
- // easier to work with nativeElement
- const input = des[2].nativeElement as HTMLInputElement;
- expect(input.style.backgroundColor).toBe('cyan', 'initial backgroundColor');
-
- // dispatch a DOM event so that Angular responds to the input value change.
- input.value = 'green';
- input.dispatchEvent(newEvent('input'));
- fixture.detectChanges();
-
- expect(input.style.backgroundColor).toBe('green', 'changed backgroundColor');
- });
-
-
- it('bare <h2> should not have a customProperty', () => {
- expect(bareH2.properties['customProperty']).toBeUndefined();
- });
一些技巧值得注意:
A few techniques are noteworthy:
当已知元素类型时,
By.directive
是一种获取拥有这个指令的元素的好方法。The
By.directive
predicate is a great way to get the elements that have this directive when their element types are unknown.By.css('h2:not([highlight])')
里的:not
伪类(pseudo-class)帮助查找不带该指令的<h2>
元素。By.css('*:not([highlight])')
查找所有不带该指令的元素。The
:not
pseudo-class inBy.css('h2:not([highlight])')
helps find<h2>
elements that do not have the directive.By.css('*:not([highlight])')
finds any element that does not have the directive.DebugElement.styles
甚至不用借助真实的浏览器也可以访问元素的样式,感谢DebugElement
提供的这层抽象! 但是如果直接使用nativeElement
会比这层抽象更简单、更清晰,也可以放心大胆的使用它。DebugElement.styles
affords access to element styles even in the absence of a real browser, thanks to theDebugElement
abstraction. But feel free to exploit thenativeElement
when that seems easier or more clear than the abstraction.Angular 将指令添加到它的元素的注入器中。默认颜色的测试程序使用第二个
<h2>
的注入器来获取它的HighlightDirective
实例以及它的defaultColor
。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
<h2>
to get itsHighlightDirective
instance and itsdefaultColor
.DebugElement.properties
让你可以访问由指令设置的自定义属性。DebugElement.properties
affords access to the artificial custom property that is set by the directive.
管道测试
Pipe Testing
管道很容易测试,无需 Angular 测试工具。
Pipes are easy to test without the Angular testing utilities.
管道类有一个方法,transform
,用来转换输入值到输出值。 transform
的实现很少与 DOM 交互。 除了 @Pipe
元数据和一个接口外,大部分管道不依赖 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.
假设 TitleCasePipe
将每个单词的第一个字母变成大写。 下面是使用正则表达式实现的简单代码:
Consider a TitleCasePipe
that capitalizes the first letter of each word. Here's a naive implementation with a regular expression.
import { Pipe, PipeTransform } from '@angular/core';
@Pipe({name: 'titlecase', pure: true})
/** Transform to Title Case: uppercase the first letter of the words in a string.*/
export class TitleCasePipe implements PipeTransform {
transform(input: string): string {
return input.length === 0 ? '' :
input.replace(/\w\S*/g, (txt => txt[0].toUpperCase() + txt.substr(1).toLowerCase() ));
}
}
任何使用正则表达式的类都值得彻底的进行测试。 使用 Jasmine 来探索预期的用例和极端的用例。
Anything that uses a regular expression is worth testing thoroughly. Use simple Jasmine to explore the expected cases and the edge cases.
- describe('TitleCasePipe', () => {
- // This pipe is a pure, stateless function so no need for BeforeEach
- let pipe = new TitleCasePipe();
-
- it('transforms "abc" to "Abc"', () => {
- expect(pipe.transform('abc')).toBe('Abc');
- });
-
- it('transforms "abc def" to "Abc Def"', () => {
- expect(pipe.transform('abc def')).toBe('Abc Def');
- });
-
- // ... more tests ...
- });
也能编写 DOM 测试
Write DOM tests too
有些管道的测试程序是孤立的。 它们不能验证 TitleCasePipe
是否在应用到组件上时是否工作正常。
These are tests of the pipe in isolation. They can't tell if the TitleCasePipe
is working properly as applied in the application components.
考虑像这样添加组件测试程序:
Consider adding component tests such as this one:
- it('should convert hero name to Title Case', () => {
- // get the name's input and display elements from the DOM
- const hostElement = fixture.nativeElement;
- const nameInput: HTMLInputElement = hostElement.querySelector('input');
- const nameDisplay: HTMLElement = hostElement.querySelector('span');
-
- // simulate user entering a new name into the input box
- nameInput.value = 'quick BROWN fOx';
-
- // dispatch a DOM event so that Angular learns of input value change.
- nameInput.dispatchEvent(newEvent('input'));
-
- // Tell Angular to update the display binding through the title pipe
- fixture.detectChanges();
-
- expect(nameDisplay.textContent).toBe('Quick Brown Fox');
- });
测试程序的调试
Test debugging
在浏览器中,像调试应用一样调试测试程序 spec。
Debug specs in the browser in the same way that you debug an application.
显示
Karma
的浏览器窗口(之前被隐藏了)。Reveal the karma browser window (hidden earlier).
点击“DEBUG”按钮;它打开一页新浏览器标签并重新开始运行测试程序
Click the DEBUG button; it opens a new browser tab and re-runs the tests.
打开浏览器的“Developer Tools”(Windows 上的 Ctrl-Shift-I 或者 OSX 上的 Command-Option-I)。
Open the browser's “Developer Tools” (
Ctrl-Shift-I
on windows;Command-Option-I
in OSX).选择“sources”页
Pick the "sources" section.
打开
1st.spec.ts
测试文件(Control/Command-P, 然后输入文件名字)。Open the
1st.spec.ts
test file (Control/Command-P, then start typing the name of the file).在测试程序中设置断点。
Set a breakpoint in the test.
刷新浏览器...然后它就会停在断点上。
Refresh the browser, and it stops at the breakpoint.
![Karma debugging](generated/images/guide/testing/karma-1st-spec-debug.png)
测试工具 API
Testing Utility APIs
本节将最有用的 Angular 测试功能提取出来,并总结了它们的作用。
This section takes inventory of the most useful Angular testing features and summarizes what they do.
Angular 的测试工具集包括 TestBed
、ComponentFixture
和一些用来控制测试环境的便捷函数。 TestBed
和 ComponentFixture
部分单独讲过它们。
The Angular testing utilities include the TestBed
, the ComponentFixture
, and a handful of functions that control the test environment. The TestBed and ComponentFixture classes are covered separately.
下面是一些独立函数的总结,以使用频率排序:
Here's a summary of the stand-alone functions, in order of likely utility:
函数 Function | 说明 Description |
---|---|
在一个特殊的 async 测试区域中运行测试( Runs the body of a test ( | |
在一个特殊的 fakeAsync 测试区域中运行测试( Runs the body of a test ( | |
通过在 fakeAsync 测试区域中刷新定时器和微任务(micro-task)队列来仿真时间的流逝以及异步活动的完成。 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. 好奇和执着的读者可能会喜欢这篇长博客: "Tasks, microtasks, queues and schedules". The curious, dedicated reader might enjoy this lengthy blog post, "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. | |
| 从当前的 Injects one or more services from the current |
当 When a 一般来讲,测试程序应该以无排队任务结束。 当待执行计时器任务存在时,调用 In general, a test should end with no queued tasks. When pending timer tasks are expected, call | |
当 When a 一般来说,测试应该等待微任务结束。 当待执行微任务存在时,调用 In general, a test should wait for micro-tasks to finish. When pending microtasks are expected, call | |
一个服务提供商令牌,用于开启自动变更检测。 A provider token for a service that turns on automatic change detection. | |
获取当前 Gets the current instance of the |
TestBed
类小结
TestBed class summary
TestBed
类是 Angular 测试工具的主要类之一。它的 API 很庞大,可能有点过于复杂,直到你一点一点的探索它们。 阅读本章前面的部分,了解了基本的知识以后,再试着了解完整 API。
The TestBed
class is one of the principal Angular testing utilities. Its API is quite large and can be overwhelming until you've explored it, a little at a time. Read the early part of this guide first to get the basics before trying to absorb the full API.
传递给 configureTestingModule
的模块定义是 @NgModule
元数据属性的子集。
The module definition passed to configureTestingModule
is a subset of the @NgModule
metadata properties.
type TestModuleMetadata = {
providers?: any[];
declarations?: any[];
imports?: any[];
schemas?: Array<SchemaMetadata | any[]>;
};
每一个重载方法接受一个 MetadataOverride<T>
,这里 T
是适合这个方法的元数据类型,也就是 @NgModule
、@Component
、@Directive
或者 @Pipe
的参数。
Each override method takes a MetadataOverride<T>
where T
is the kind of metadata appropriate to the method, that is, the parameter of an @NgModule
, @Component
, @Directive
, or @Pipe
.
type MetadataOverride = {
add?: Partial;
remove?: Partial;
set?: Partial;
};
TestBed
的 API 包含了一系列静态类方法,它们更新或者引用全局的 TestBed
实例。
The TestBed
API consists of static class methods that either update or reference a global instance of theTestBed
.
在内部,所有静态方法在 getTestBed()
函数返回的当前运行时间的 TestBed
实例上都有对应的方法。
Internally, all static methods cover methods of the current runtime TestBed
instance, which is also returned by the getTestBed()
function.
在 BeforeEach()
内调用 TestBed
方法,以确保在运行每个单独测试时,都有崭新的开始。
Call TestBed
methods within a beforeEach()
to ensure a fresh start before each individual test.
这里列出了最重要的静态方法,以使用频率排序:
Here are the most important static methods, in order of likely utility.
方法 Methods | 说明 Description |
---|---|
| 测试垫片( The testing shims ( 调用 Call |
| 在配置好测试模块之后,异步编译它。 如果测试模块中的任何一个组件具有 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 调用完 After calling |
| 基于当前 Create an instance of a component of type |
| 替换指定的 Replace metadata for the given |
| 替换指定组件类的元数据,该组件类可能嵌套在一个很深的内部模块中。 Replace metadata for the given component class, which could be nested deeply within an inner module. |
| 替换指定指令类的元数据,该指令可能嵌套在一个很深的内部模块中。 Replace metadata for the given directive class, which could be nested deeply within an inner module. |
| 替换指定管道类的元数据,该管道可能嵌套在一个很深的内部模块中。 Replace metadata for the given pipe class, which could be nested deeply within an inner module. |
| 从当前 Retrieve a service from the current The 如果该服务是可选的呢? What if the service is optional? The
一旦调用, After calling |
| 为整套测试的运行初始化测试环境。 Initialize the testing environment for the entire test run. 测试垫片( The testing shims ( 这个方法只能被调用一次。如果确实需要在测试程序运行期间改变这个默认设置,那么先调用 You may call this method exactly once. If you must change this default in the middle of your test run, call 指定 Angular 编译器工厂, Specify the Angular compiler factory, a |
| 重设初始测试环境,包括默认测试模块在内。 Reset the initial test environment, including the default testing module. |
少数 TestBed
实例方法没有对应的静态方法。它们很少被使用。
A few of the TestBed
instance methods are not covered by static TestBed
class methods. These are rarely needed.
ComponentFixture
类
The ComponentFixture
TestBed.createComponent<T>
会创建一个组件 T
的实例,并为该组件返回一个强类型的 ComponentFixture
。
The TestBed.createComponent<T>
creates an instance of the component T
and returns a strongly typed ComponentFixture
for that component.
ComponentFixture
的属性和方法提供了对组件、它的 DOM 和它的 Angular 环境方面的访问。
The ComponentFixture
properties and methods provide access to the component, its DOM representation, and aspects of its Angular environment.
ComponentFixture
的属性
ComponentFixture properties
下面是对测试最重要的属性,以使用频率排序:
Here are the most important properties for testers, in order of likely utility.
属性 Properties | 说明 Description |
---|---|
| 被 The instance of the component class created by |
与组件根元素关联的 The The | |
| 组件的原生根 DOM 元素。 The native DOM element at the root of the component. |
| 组件的 The 在测试一个拥有 The |
ComponentFixture
的方法
ComponentFixture methods
fixture 方法使 Angular 对组件树执行某些任务。 在触发 Angular 行为来模拟的用户行为时,调用这些方法。
The fixture methods cause Angular to perform certain tasks on the component tree. Call these method to trigger Angular behavior in response to simulated user action.
下面是对测试最有用的方法。
Here are the most useful methods for testers.
方法 Methods | 说明 Description |
---|---|
| 为组件触发一轮变化检查。 Trigger a change detection cycle for the component. 调用它来初始化组件(它调用 Call it to initialize the component (it calls 之后,运行 Runs |
| 如果你希望这个夹具自动检测变更,就把这个设置为 Set this to 当自动检测打开时,测试 fixture 监听 zone 事件,并调用 When autodetect is 默认值是 The default is |
| 运行一次变更检测来确认没有待处理的变化。如果有未处理的变化,它将抛出一个错误。 Do a change detection run to make sure there are no pending changes. Throws an exceptions if there are. |
| 如果 fixture 当前是稳定的,则返回 If the fixture is currently stable, returns |
| 返回一个承诺,在 fixture 稳定时解析。 Returns a promise that resolves when the fixture is stable. 要想在完成了异步活动或异步变更检测之后再继续测试,可以对那个承诺对象进行挂钩。 参见 前面。 To resume testing after completion of asynchronous activity or asynchronous change detection, hook that promise. See above. |
| 触发组件的销毁。 Trigger component destruction. |
DebugElement
DebugElement
提供了对组件的 DOM 的访问。
The DebugElement
provides crucial insights into the component's DOM representation.
fixture.debugElement
返回测试根组件的 DebugElement
,通过它你可以访问(查询)fixture 的整个元素和组件子树。
From the test root component's DebugElement
returned by fixture.debugElement
, you can walk (and query) the fixture's entire element and component subtrees.
下面是 DebugElement
最有用的成员,以使用频率排序。
Here are the most useful DebugElement
members for testers, in approximate order of utility:
成员 Member | 说明 Description |
---|---|
| 与浏览器中 DOM 元素对应(WebWorkers 时,值为 null)。 The corresponding DOM element in the browser (null for WebWorkers). |
调用 Calling | |
| 调用 Calling |
| 宿主依赖注入器。 比如,根元素的组件实例注入器。 The host dependency injector. For example, the root element's component instance injector. |
| 元素自己的组件实例(如果有)。 The element's own component instance, if it has one. |
| 为元素提供父级上下文的对象。 通常是控制该元素的祖级组件实例。 An object that provides parent context for this element. Often an ancestor component instance that governs this element. 当一个元素被 When an element is repeated within |
| The immediate |
| The |
| 元素的标签名字,如果它是一个元素的话。 The element tag name, if it is an element. |
| 如果在该元素的 Triggers the event by its name if there is a corresponding listener in the element's 如果事件缺乏监听器,或者有其它问题,考虑调用 If the event lacks a listener or there's some other problem, consider calling |
元素的 The callbacks attached to the component's | |
组件注入器的查询令牌。 包括组件自己的令牌和组件的 This component's injector lookup tokens. Includes the component itself plus the tokens that the component lists in its | |
| source 是在源组件模板中查询这个元素的处所。 Where to find this element in the source component template. |
与模板本地变量(比如 Dictionary of objects associated with template local variables (e.g. |
DebugElement.query(predicate)
和 DebugElement.queryAll(predicate)
方法接受一个条件方法, 它过滤源元素的子树,返回匹配的 DebugElement
。
The DebugElement.query(predicate)
and DebugElement.queryAll(predicate)
methods take a predicate that filters the source element's subtree for matching DebugElement
.
这个条件方法是任何接受一个 DebugElement
并返回真值的方法。 下面的例子查询所有拥有名为 content
的模块本地变量的所有 DebugElement
:
The predicate is any method that takes a DebugElement
and returns a truthy value. The following example finds all DebugElements
with a reference to a template local variable named "content":
// Filter for DebugElements with a #content reference
const contentRefs = el.queryAll( de => de.references['content']);
Angular 的 By
类为常用条件方法提供了三个静态方法:
The Angular By
class has three static methods for common predicates:
By.all
- 返回所有元素By.all
- return all elements.By.css(selector)
- 返回符合 CSS 选择器的元素。By.css(selector)
- return elements with matching CSS selectors.By.directive(directive)
- 返回 Angular 能匹配一个指令类实例的所有元素。By.directive(directive)
- return elements that Angular matched to an instance of the directive class.
// Can find DebugElement either by css selector or by directive
const h2 = fixture.debugElement.query(By.css('h2'));
const directive = fixture.debugElement.query(By.directive(HighlightDirective));
常见问题
Frequently Asked Questions
为什么要把测试文件和被测文件放在一起?
Why put spec file next to the file it tests?
将单元测试的 spec 配置文件放到与应用程序源代码文件所在的同一个文件夹中是个好主意,因为:
It's a good idea to put unit test spec files in the same folder as the application source code files that they test:
这样的测试程序很容易被找到
Such tests are easy to find.
你可以一眼看出应用程序的哪些部分缺乏测试程序。
You see at a glance if a part of your application lacks tests.
临近的测试程序可以展示代码是如何在上下文中工作的
Nearby tests can reveal how a part works in context.
当你移动代码(无可避免)时,你记得一起移动测试程序
When you move the source (inevitable), you remember to move the test.
当你重命名源代码文件(无可避免),你记得重命名测试程序文件。
When you rename the source file (inevitable), you remember to rename the test file.
什么时候我该把测试文件放进单独的 test
文件夹中?
When would I put specs in a test folder?
应用程序的整合测试 spec 文件可以测试横跨多个目录和模块的多个部分之间的互动。 它们不属于任何部分,很自然,没有特别的地方存放它们。
Application integration specs can test the interactions of multiple parts spread across folders and modules. They don't really belong to any part in particular, so they don't have a natural home next to any one file.
通常,在 test
目录中为它们创建一个合适的目录比较好。
It's often better to create an appropriate folder for them in the tests
directory.
当然,测试助手对象的测试 spec 文件也属于 test
目录,与它们对应的助手文件相邻。
Of course specs that test the test helpers belong in the test
folder, next to their corresponding helper files.
为什么不依赖 E2E 测试来保障 DOM 集成后的正确性?
Why not rely on E2E tests of DOM integration?
本指南中讲的组件 DOM 测试通常需要大量的准备工作以及高级技巧,不像只针对类的测试那样简单。
The component DOM tests described in this guide often require extensive setup and advanced techniques whereas the unit tests are comparatively simple.
为什么不等到端到端(E2E)测试阶段再对 DOM 进行集成测试呢?
Why not defer DOM integration tests to end-to-end (E2E) testing?
E2E 测试对于整个系统的高层验证非常好用。 但是它们没法给你像单元测试这样全面的测试覆盖率。
E2E tests are great for high-level validation of the entire system. But they can't give you the comprehensive test coverage that you'd expect from unit tests.
E2E 测试很难写,并且执行性能也赶不上单元测试。 它们很容易被破坏,而且经常是因为某些远离故障点的修改或不当行为而导致的。
E2E tests are difficult to write and perform poorly compared to unit tests. They break easily, often due to changes or misbehavior far removed from the site of breakage.
当出错时,E2E 测试不能轻松揭露你的组件出了什么问题, 比如丢失或错误的数据、网络失去连接或远端服务器挂了。
E2E tests can't easily reveal how your components behave when things go wrong, such as missing or bad data, lost connectivity, and remote service failures.
如果 E2E 的测试对象要更新数据库、发送发票或收取信用卡,就需要一些特殊的技巧和后门来防止远程资源被意外破坏。 它甚至可能都难以导航到你要测试的组件。
E2E tests for apps that update a database, send an invoice, or charge a credit card require special tricks and back-doors to prevent accidental corruption of remote resources. It can even be hard to navigate to the component you want to test.
由于存在这么多障碍,你应该尽可能使用单元测试技术来测试 DOM 交互。
Because of these many obstacles, you should test DOM interaction with unit testing techniques as much as possible.