测试link

Testinglink

该指南提供了对 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:

• 范例应用范例应用 / 下载范例

  Sample appSample app / 下载范例

• 测试测试 / 下载范例

  TestsTests / 下载范例

准备工作link

Setuplink

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 testCLI command:

      
        content_copy
      
      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:

      
        content_copy
      
      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.

大多数人都会觉得浏览器中的报告比控制台中的日志更容易阅读。 你可以点击一行测试，来单独重跑这个测试，或者点击一行描述信息来重跑所选测试组（“测试套件”）中的那些测试。

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.

配置link

Configurationlink

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.

其它测试框架link

Other test frameworkslink

你还可以使用其它的测试库和测试运行器来对 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.

测试文件名及其位置link

Test file name and locationlink

查看 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.

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.

建立持续集成环境link

Set up continuous integrationlink

避免项目出 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 配置项目link

Configure project for Circle CIlink

步骤一：在项目的根目录下创建一个名叫 .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:

      
        content_copy
      
      
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 runto 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 配置项目link

Configure project for Travis CIlink

步骤一：在项目根目录下创建一个名叫 .travis.yml 的文件，内容如下：

Step 1: Create a file called .travis.yml at the project root, with the following content:

      
        content_copy
      
      
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 测试而配置 CLIlink

Configure CLI for CI testing in Chromelink

当 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:

      
        content_copy
      
      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 original protractor.conf.js.

      
        content_copy
      
      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:

      
        content_copy
      
      ng test -- --no-watch --no-progress --browsers=ChromeHeadlessCI
ng e2e -- --protractor-config=e2e/protractor-ci.conf.js
    

启用代码覆盖率报告link

Enable code coverage reportslink

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.

      
        content_copy
      
      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:

      
        content_copy
      
      "test": {
  "options": {
    "codeCoverage": true
  }
}
    

代码覆盖率实施link

Code coverage enforcementlink

代码覆盖率能让你估计要测试的代码量。 如果你的开发组决定要设置单元测试的最小数量，就可以使用 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.

      
        content_copy
      
      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.

对服务的测试link

Service Testslink

服务通常是单元测试中最简单的文件类型。 下面是一些针对 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.

      
        content_copy
      
      
// 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();
    });
  });
});
    

带有依赖的服务link

Services with dependencieslink

服务通常会依赖于一些 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:

      
        content_copy
      
      @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.

      
        content_copy
      
      
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.

这些标准的测试技巧对于在隔离的环境下对服务进行单元测试非常重要。

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（测试机床）测试服务link

Testing services with the TestBedlink

你的应用中会依赖 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 TestBedlink

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.

      
        content_copy
      
      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.

      
        content_copy
      
      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.

      
        content_copy
      
      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.

      
        content_copy
      
      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.

      
        content_copy
      
      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 进行测试link

Testing without beforeEach()link

本指南中的大多数的测试套件都会调用 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().

      
        content_copy
      
      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.

      
        content_copy
      
      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.

      
        content_copy
      
      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 服务link

Testing HTTP serviceslink

那些会向远端服务器发起 HTTP 调用的数据服务，通常会注入 Angular 的 HttpClient服务并委托它进行 XHR 调用。

Data services that make HTTP calls to remote servers typically inject and delegate to the Angular HttpClientservice for XHR calls.

你可以像测试其它带依赖的服务那样，通过注入一个 HttpClient 间谍来测试这种数据服务。

You can test a data service with an injected HttpClient spy as you would test any service with a dependency.

      
        content_copy
      
      
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')
  );
});
    

HttpClientTestingModulelink

如果将来 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.

组件测试基础link

Component Test Basicslink

组件与 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.

单独测试组件类link

Component class testinglink

你可以像测试服务类一样测试组件类。

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.

      
        content_copy
      
      @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.

      
        content_copy
      
      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.

      
        content_copy
      
      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.

      
        content_copy
      
      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.

      
        content_copy
      
      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.

      
        content_copy
      
      class MockUserService {
  isLoggedIn = true;
  user = { name: 'Test User'};
};
    

然后在 TestBed 的配置中提供并同时注入该组件和该服务。

Then provide and inject both the component and the service in the TestBed configuration.

      
        content_copy
      
      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.

      
        content_copy
      
      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 的测试link

Component DOM testinglink

测试组件类就像测试服务那样简单。

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 生成的测试link

CLI-generated testslink

当你用 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):

      
        content_copy
      
      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:

      
        content_copy
      
      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();
  });
});
    

缩减环境准备代码link

Reduce the setuplink

这个文件中只有最后三行是真正测试组件的，它们用来断言 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:

      
        content_copy
      
      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.

      
        content_copy
      
      TestBed.configureTestingModule({
  declarations: [ BannerComponent ]
});
    

createComponent()link

在配置好 TestBed 之后，你还可以调用它的 createComponent() 方法。

After configuring TestBed, you call its createComponent() method.

      
        content_copy
      
      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.

ComponentFixturelink

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:

      
        content_copy
      
      const component = fixture.componentInstance;
expect(component).toBeDefined();
    

beforeEach()link

随着该组件的成长，你将会添加更多测试。 除了为每个测试都复制一份 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:

      
        content_copy
      
      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.

      
        content_copy
      
      it('should contain "banner works!"', () => {
  const bannerElement: HTMLElement = fixture.nativeElement;
  expect(bannerElement.textContent).toContain('banner works!');
});
    

nativeElementlink

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:

      
        content_copy
      
      it('should have <p> with "banner works!"', () => {
  const bannerElement: HTMLElement = fixture.nativeElement;
  const p = bannerElement.querySelector('p');
  expect(p.textContent).toEqual('banner works!');
});
    

DebugElementlink

Angular 的夹具可以通过 fixture.nativeElement 直接提供组件的元素。

The Angular fixture provides the component's element directly through the fixture.nativeElement.

      
        content_copy
      
      const bannerElement: HTMLElement = fixture.nativeElement;
    

它实际上是 fixture.debugElement.nativeElement 的一个便利方法。

This is actually a convenience method, implemented as fixture.debugElement.nativeElement.

      
        content_copy
      
      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:

      
        content_copy
      
      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.

      
        content_copy
      
      import { DebugElement } from '@angular/core';
    

By.css()link

虽然本章中的测试都是运行在浏览器中的，不过有些应用可能会运行在其它平台上（至少一部分时间是这样）。

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:

      
        content_copy
      
      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.

      
        content_copy
      
      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 selects DebugElement 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.

组件测试场景link

Component Test Scenarioslink

下面这些部分构成了本指南的大部分内容，它们将探讨一些常见的组件测试场景。

The following sections, comprising most of this guide, explore common component testing scenarios

组件绑定link

Component bindinglink

当前的 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.

      
        content_copy
      
      @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>link

Query for the <h1>link

你将会写一系列测试来探查 <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.

      
        content_copy
      
      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() 函数不会绑定数据link

createComponent() does not bind datalink

你的第一个测试希望看到屏幕显示出了默认的 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:

      
        content_copy
      
      it('should display original title', () => {
  expect(h1.textContent).toContain(component.title);
});
    

但测试失败了，给出如下信息：

That test fails with the message:

      
        content_copy
      
      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:

      
        content_copy
      
      it('no title in the DOM after createComponent()', () => {
  expect(h1.textContent).toEqual('');
});
    

detectChanges()link

你必须通过调用 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.

      
        content_copy
      
      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().

      
        content_copy
      
      it('should display a different test title', () => {
  component.title = 'Test Title';
  fixture.detectChanges();
  expect(h1.textContent).toContain('Test Title');
});
    

自动变更检测link

Automatic change detectionlink

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:

      
        content_copy
      
      import { ComponentFixtureAutoDetect } from '@angular/core/testing';
    

然后把它添加到测试模块配置的 providers 数组中：

Then add it to the providers array of the testing module configuration:

      
        content_copy
      
      TestBed.configureTestingModule({
  declarations: [ BannerComponent ],
  providers: [
    { provide: ComponentFixtureAutoDetect, useValue: true }
  ]
});
    

这三个测试阐明了自动变更检测的工作原理。

Here are three tests that illustrate how automatic change detection works.

      
        content_copy
      
      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.

使用 dispatchEvent() 修改输入值link

Change an input value with dispatchEvent()link

要想模拟用户输入，你就要找到 <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.

      
        content_copy
      
      
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');
});
    

带有外部文件的组件link

Component with external fileslink

上面的 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.

      
        content_copy
      
      @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:

      
        content_copy
      
      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.

带依赖的组件link

Component with a dependencylink

组件经常依赖其他服务。

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:

      
        content_copy
      
      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:

      
        content_copy
      
      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.

提供服务的测试替身link

Provide service test doubleslink

被测试的组件不一定要注入真正的服务。实际上，服务的替身（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:

      
        content_copy
      
      let userServiceStub: Partial<UserService>;

userServiceStub = {
  isLoggedIn: true,
  user: { name: 'Test User'}
};
    

获取注入的服务link

Get injected serviceslink

测试程序需要访问被注入到 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.

      
        content_copy
      
      // UserService actually injected into the component
userService = fixture.debugElement.injector.get(UserService);
    

TestBed.get()link

你也可能通过 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:

      
        content_copy
      
      // UserService from the root injector
userService = TestBed.get(UserService);
    

总是从注入其中获取服务link

Always get the service from an injectorlink

请不要引用测试代码里提供给测试模块的 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.

      
        content_copy
      
      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);
});
    

最终的准备及测试代码link

Final setup and testslink

下面是使用 TestBed.get() 的完整的 beforeEach()：

Here's the complete beforeEach(), using TestBed.get():

      
        content_copy
      
      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:

      
        content_copy
      
      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.

接下来的测试程序确认当服务返回不同的值时组件的逻辑是否工作正常。 第二个测试程序验证变换用户名字的效果。 第三个测试程序检查如果用户没有登录，组件是否显示正确消息。

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.

带有异步服务的组件link

Component with async servicelink

在这个例子中，AboutComponent 的模板中还有一个 TwainComponent。 TwainComponent 用于显示引自马克·吐温的话。

In this sample, the AboutComponent template hosts a TwainComponent. The TwainComponent displays Mark Twain quotes.

      
        content_copy
      
      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.

      
        content_copy
      
      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）进行测试link

Testing with a spylink

当测试组件时，只应该关心服务的公共 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:

      
        content_copy
      
      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.

      
        content_copy
      
      // 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.

同步测试link

Synchronous testslink

同步 Observable 的一大优点就是你可以把那些异步的流程转换成同步测试。

A key advantage of a synchronous Observable is that you can often turn asynchronous processes into synchronous tests.

      
        content_copy
      
      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() 进行异步测试link

Async test with fakeAsync()link

要使用 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.

      
        content_copy
      
      
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.

      
        content_copy
      
      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() 函数link

The tick() functionlink

你必须调用 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.

      
        content_copy
      
      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）link

Comparing dates inside fakeAsync()link

fakeAsync() 可以模拟时光的流逝，它允许你在 fakeAsync() 中计算日期之间的差异。

fakeAsync() simulates passage of time, which allows you to calculate the difference between dates inside fakeAsync().

      
        content_copy
      
      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()link

jasmine.clock with fakeAsync()link

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.

      
        content_copy
      
      (window as any)['__zone_symbol__fakeAsyncPatchLock'] = true;
import 'zone.js/dist/zone-testing';
    

      
        content_copy
      
      
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）link

Using the RxJS scheduler inside fakeAsync()link

你还可以在 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.

      
        content_copy
      
      
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）link

Support more macroTaskslink

默认情况下，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.

      
        content_copy
      
      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);
  }));
});