This guide offers tips and techniques for testing Angular applications.
Though this page includes some general testing principles and techniques,
the focus is on testing applications written with Angular.
This guide presents tests of a sample application that is much like the Tour of Heroes tutorial.
The sample application and all tests in this guide are available as live examples for inspection, experiment, and download:
Reveals mistakes in design and implementation.
Tests shine a harsh light on the code from many angles.
When a part of the application seems hard to test, the root cause is often a design flaw,
something to cure now rather than later when it becomes expensive to fix.
本章假设你熟悉测试。但是如果你不熟悉也没有关系。有很多书本和在线资源可以帮助你。
This chapter assumes that you know something about testing. Don't worry if you don't.
There are plenty of books and online resources to get up to speed.
Angular testing utilities create a test environment
for the Angular application code under test.
Use them to condition and control parts of the application as they
interact within the Angular environment.
The karma test runner
is ideal for writing and running unit tests while developing the application.
It can be an integral part of the project's development and continuous integration processes.
This guide describes how to set up and run tests with karma.
Use protractor to write and run end-to-end (e2e) tests.
End-to-end tests explore the application as users experience it.
In e2e testing, one process runs the real application
and a second process runs protractor tests that simulate user behavior
and assert that the application respond in the browser as expected.
环境设置
Setup
要开始单元测试，有两条捷径：
There are two fast paths to getting started with unit testing.
Both approaches install npm packages, files, and scripts pre-configured for applications
built in their respective modalities.
Their artifacts and procedures differ slightly but their essentials are the same
and there are no differences in the test code.
Isolated unit tests
examine an instance of a class all by itself without any dependence on Angular or any injected values.
The tester creates a test instance of the class with new, supplying test doubles for the constructor parameters as needed, and
then probes the test instance API surface.
我们应该为管道和服务书写独立单元测试。
You should write isolated unit tests for pipes and services.
You can test components in isolation as well.
However, isolated unit tests don't reveal how components interact with Angular.
In particular, they can't reveal how a component class interacts with its own template or with other components.
Such tests require the Angular testing utilities.
The Angular testing utilities include the TestBed class and several helper functions from @angular/core/testing.
They are the main focus of this guide and you'll learn about them
when you write your first component test.
A comprehensive review of the Angular testing utilities appears later in this guide.
但首先，我们要先随便写一个测试来验证测试环境是否已经就绪了，并掌握一些基础的测试技术。
But first you should write a dummy test to verify that your test environment is set up properly
and to lock in a few basic testing skills.
The command compiles the application and test code and starts karma.
Both processes watch pertinent files, write messages to the console, and re-run when they detect changes.
The documentation setup defines the test command in the scripts section of npm's package.json.
The Angular CLI has different commands to do the same thing. Adjust accordingly.
等一小段时间后，Karma便打开浏览器并开始向控制台输出。
After a few moments, karma opens a browser and starts writing to the console.
隐藏（不要关闭）浏览器，查看控制台的输出，应该是这样的：
Hide (don't close!) the browser and focus on the console output, which
should look something like this:
> npm test
...[0]1:37:03 PM -Compilation complete.Watchingfor file changes....[1]Chrome51.0.2704:Executed0 of 0 SUCCESS
Chrome51.0.2704:Executed1 of 1 SUCCESS
SUCCESS (0.005 secs /0.005 secs)
编译器和Karma都会持续运行。编译器的输入信息前面有[0]，Karma的输出前面有[1]。
Both the compiler and karma continue to run. The compiler output is preceded by [0];
the karma output by [1].
将期望从true变换为false。
Change the expectation from true to false.
编译器监视器检测到这个变化并重新编译。
The compiler watcher detects the change and recompiles.
An Angular component is the first thing most developers want to test.
The BannerComponent in src/app/banner-inline.component.ts is the simplest component in this application and
a good place to start.
It presents the application title at the top of the screen within an <h1> tag.
src/app/banner-inline.component.ts
import{Component}from'@angular/core';@Component({
selector:'app-banner',template:'<h1>{{title}}</h1>'})exportclassBannerComponent{
title ='Test Tour of Heroes';}
This version of the BannerComponent has an inline template and an interpolation binding.
The component is probably too simple to be worth testing in real life but
it's perfect for a first encounter with the Angular testing utilities.
describe('BannerComponent (inline template)',()=>{let comp:BannerComponent;let fixture:ComponentFixture<BannerComponent>;let de:DebugElement;let el:HTMLElement;
beforeEach(()=>{TestBed.configureTestingModule({
declarations:[BannerComponent],// declare the test component});
fixture =TestBed.createComponent(BannerComponent);
comp = fixture.componentInstance;// BannerComponent test instance// query for the title <h1> by CSS element selector
de = fixture.debugElement.query(By.css('h1'));
el = de.nativeElement;});});
TestBed is the first and most important of the Angular testing utilities.
It creates an Angular testing module—an @NgModule class—that
you configure with the configureTestingModule method to produce the module environment for the class you want to test.
In effect, you detach the tested component from its own application module
and re-attach it to a dynamically-constructed Angular test module
tailored specifically for this battery of tests.
The configureTestingModule method takes an @NgModule-like metadata object.
The metadata object can have most of the properties of a normal Angular module.
This metadata object simply declares the component to test, BannerComponent.
The metadata lack imports because (a) the default testing module configuration already has what BannerComponent needs
and (b) BannerComponent doesn't interact with any other components.
The base state includes a default testing module configuration consisting of the
declarables (components, directives, and pipes) and providers (some of them mocked)
that almost everyone needs.
This default configuration is merely a foundation for testing an app.
Later you'll call TestBed.configureTestingModule with more metadata that define additional
imports, declarations, providers, and schemas to fit your application tests.
Optional override methods can fine-tune aspects of the configuration.
After configuring TestBed, you tell it to create an instance of the component-under-test.
In this example, TestBed.createComponent creates an instance of BannerComponent and
returns a component test fixture.
在调用了createComponent之后就不要再重新配置TestBed了。
Do not re-configure TestBed after calling createComponent.
The createComponent method closes the current TestBed instance to further configuration.
You cannot call any more TestBed configuration methods, not configureTestingModule
nor any of the override... methods. If you try, TestBed throws an error.
The createComponent method returns a ComponentFixture, a handle on the test environment surrounding the created component.
The fixture provides access to the component instance itself and
to the DebugElement, which is a handle on the component's DOM element.
The query method takes a predicate function and searches the fixture's entire DOM tree for the
first element that satisfies the predicate.
The result is a differentDebugElement, one associated with the matching DOM element.
queryAll方法返回一列数组，包含所有DebugElement中满足predicate的元素。
The queryAll method returns an array of allDebugElements that satisfy the predicate.
A predicate is a function that returns a boolean.
A query predicate receives a DebugElement and returns true if the element meets the selection criteria.
The By class is an Angular testing utility that produces useful predicates.
Its By.css static method produces a
standard CSS selector
predicate that filters the same way as a jQuery selector.
Finally, the setup assigns the DOM element from the DebugElementnativeElement property to el.
The tests assert that el contains the expected title text.
测试程序
The tests
再每个测试程序之前，Jasmin都一次运行beforeEach函数：
Jasmine runs the beforeEach function before each of these tests
src/app/banner-inline.component.spec.ts (tests)
it('should display original title',()=>{
fixture.detectChanges();
expect(el.textContent).toContain(comp.title);});
it('should display a different test title',()=>{
comp.title ='Test Title';
fixture.detectChanges();
expect(el.textContent).toContain('Test Title');});
这些测试程序向DebugElement获取原生HTML元素，来满足自己的期望。
These tests ask the DebugElement for the native HTML element to satisfy their expectations.
detectChanges：在测试中的Angular变更检测
detectChanges: Angular change detection within a test
Each test tells Angular when to perform change detection by calling fixture.detectChanges().
The first test does so immediately, triggering data binding and propagation of the title property
to the DOM element.
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.
The TestBed.createComponent does not trigger change detection.
The fixture does not automatically push the component's title property value into the data bound element,
a fact demonstrated in the following test:
src/app/banner-inline.component.spec.ts (no detectChanges)
it('no title in the DOM until manually call `detectChanges`',()=>{
expect(el.textContent).toEqual('');});
This behavior (or lack of it) is intentional.
It gives the tester an opportunity to inspect or change the state of
the component before Angular initiates data binding or calls lifecycle hooks.
The BannerComponent tests frequently call detectChanges.
Some testers prefer that the Angular test environment run change detection automatically.
That's possible by configuring the TestBed with the ComponentFixtureAutoDetect provider .
First import it from the testing utility library :
it('should display original title',()=>{// Hooray! No `fixture.detectChanges()` needed
expect(el.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(el.textContent).toContain(oldTitle);});
it('should display updated title after detectChanges',()=>{
comp.title ='Test Title';
fixture.detectChanges();// detect changes explicitly
expect(el.textContent).toContain(comp.title);});
第一个测试程序展示了自动检测的好处。
The first test shows the benefit of automatic change detection.
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.
Rather than wonder when the test fixture will or won't perform change detection,
the samples in this guide always calldetectChanges()explicitly.
There is no harm in calling detectChanges() more often than is strictly necessary.
The application's actual BannerComponent behaves the same as the version above but is implemented differently.
It has external template and css files, specified in templateUrl and styleUrls properties.
src/app/banner.component.ts
import{Component}from'@angular/core';@Component({
selector:'app-banner',
templateUrl:'./banner.component.html',
styleUrls:['./banner.component.css']})exportclassBannerComponent{
title ='Test Tour of Heroes';}
That's a problem for the tests.
The TestBed.createComponent method is synchronous.
But the Angular template compiler must read the external files from the file system before it can create a component instance.
That's an asynchronous activity.
The previous setup for testing the inline component won't work for a component with an external template.
The test setup for BannerComponent must give the Angular template compiler time to read the files.
The logic in the beforeEach of the previous spec is split into two beforeEach calls.
The first beforeEach handles asynchronous compilation.
// async beforeEach
beforeEach(async(()=>{TestBed.configureTestingModule({
declarations:[BannerComponent],// declare the test component}).compileComponents();// compile template and css}));
Notice the async function called as the argument to beforeEach.
The async function is one of the Angular testing utilities and
has to be imported.
import{ async }from'@angular/core/testing';
它接收一个无参数的函数，并返回一个函数，这个函数会作为实参传给beforeEach。
It takes a parameterless function and returns a function
which becomes the true argument to the beforeEach.
async参数的内容看起来非常像同步版beforeEach的函数体。
它并不能很明显的看出来这是异步函数。
比如它不返回承诺（Promise），并且也没有标准Jasmine异步测试时常用的done函数作为参数。
内部实现上，async会把beforeEach的函数体放进一个特殊的异步测试区（async test zone），它隐藏了异步执行的内部机制。
The body of the async argument looks much like the body of a synchronous beforeEach.
There is nothing obviously asynchronous about it.
For example, it doesn't return a promise and
there is no done function to call as there would be in standard Jasmine asynchronous tests.
Internally, async arranges for the body of the beforeEach to run in a special async test zone
that hides the mechanics of asynchronous execution.
这就是为了调用异步的TestBed.compileComponents方法所要做的一切。
All this is necessary in order to call the asynchronous TestBed.compileComponents method.
The TestBed.compileComponents method asynchronously compiles all the components configured in the testing module.
In this example, the BannerComponent is the only component to compile.
When compileComponents completes, the external templates and css files have been "inlined"
and TestBed.createComponent can create new instances of BannerComponent synchronously.
WebPack developers need not call compileComponents because it inlines templates and css
as part of the automated build process that precedes running the test.
In this example, TestBed.compileComponents only compiles the BannerComponent.
Tests later in the guide declare multiple components and
a few specs import entire application modules that hold yet more components.
Any of these components might have external templates and css files.
TestBed.compileComponents compiles all of the declared components asynchronously at one time.
Do not configure the TestBed after calling compileComponents.
Make compileComponents the last step
before calling TestBed.createComponent to instantiate the component-under-test.
Calling compileComponents closes the current TestBed instance is 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.
第二个同步beforeEach
The second synchronous beforeEach
这个同步的beforeEach包含异步beforeEach之后的其余步骤。
A synchronousbeforeEach containing the remaining setup steps follows the asynchronous beforeEach.
// synchronous beforeEach
beforeEach(()=>{
fixture =TestBed.createComponent(BannerComponent);
comp = fixture.componentInstance;// BannerComponent test instance// query for the title <h1> by CSS element selector
de = fixture.debugElement.query(By.css('h1'));
el = de.nativeElement;});
These are the same steps as in the original beforeEach.
They include creating an instance of the BannerComponent and querying for the elements to inspect.
测试运行器（runner）会先等待第一个异步beforeEach函数执行完再调用第二个。
You can count on the test runner to wait for the first asynchronous beforeEach to finish before calling the second.
The compileComponents method returns a promise so you can perform additional tasks immediately after it finishes.
For example, you could move the synchronous code in the second beforeEach
into a compileComponents().then(...) callback and write only one beforeEach.
大多数开发人员会觉得这样不易读，因此，更多采用的还是写两个beforeEach调用的方式。
Most developers find that hard to read.
The two beforeEach calls are widely preferred.
The Quickstart seed provides a similar test of its AppComponent
as you can see in thislive example / downloadable example.
It too calls compileComponents although it doesn't have to because the AppComponent's template is inline.
There's no harm in it and you might call compileComponents anyway
in case you decide later to re-factor the template into a separate file.
The tests in this guide only call compileComponents when necessary.
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, src/app/welcome.component.spec.ts:
src/app/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 }]});
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.
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.
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.
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.
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.
WelcomeComponent's injector
// UserService actually injected into the component
userService = fixture.debugElement.injector.get(UserService);
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.
Fortunately, in this test suite, the only provider of UserService is the root testing module,
so it is safe to call TestBed.get as follows:
TestBed injector
// UserService from the root injector
userService =TestBed.get(UserService);
For a use case in which inject and TestBed.get do not work,
see the section Override a component's providers, which
explains why you must get the service from the component's injector instead.
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:
src/app/welcome.component.spec.ts
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)
de = fixture.debugElement.query(By.css('.welcome'));
el = de.nativeElement;});
下面是一些测试程序:
And here are some tests:
src/app/welcome.component.spec.ts
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 second parameter to the Jasmine it (e.g., 'expected name') is an optional addendum.
If the expectation fails, Jasmine displays this addendum after 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.
The TwainService implementation is irrelevant for this particular test.
It is sufficient to see within ngOnInit that twainService.getQuote returns a promise, which means it is asynchronous.
In general, tests should not make calls to remote servers.
They should emulate such calls. The setup in this src/app/shared/twain.component.spec.ts shows one way to do that:
src/app/shared/twain.component.spec.ts (setup)
beforeEach(()=>{TestBed.configureTestingModule({
declarations:[TwainComponent],
providers:[TwainService],});
fixture =TestBed.createComponent(TwainComponent);
comp = fixture.componentInstance;// TwainService actually injected into the component
twainService = fixture.debugElement.injector.get(TwainService);// Setup spy on the `getQuote` method
spy = spyOn(twainService,'getQuote').and.returnValue(Promise.resolve(testQuote));// Get the Twain quote element by CSS selector (e.g., by class name)
de = fixture.debugElement.query(By.css('.twain'));
el = de.nativeElement;});
This setup is similar to the welcome.component.spec setup.
But instead of creating a stubbed service object, it injects the real service (see the testing module providers) and
replaces the critical getQuote method with a Jasmine spy.
The spy is designed such that any call to getQuote receives an immediately resolved promise with a test quote.
The spy bypasses the actual getQuote method and therefore does not contact the server.
伪造服务实例和刺探真实服务都是好方法。挑选一种对当前测试套件最简单的方法。你可以随时改变主意。
Faking a service instance and spying on the real service are both great options.
Pick the one that seems easiest for the current test suite.
Don't be afraid to change your mind.
Spying on the real service isn't always easy, especially when the real service has injected dependencies.
You can stub and spy at the same time, as shown in an example below.
The first two tests are synchronous.
Thanks to the spy, they verify that getQuote is called after
the first change detection cycle during which Angular calls ngOnInit.
两者都不能证明被显示的值是服务提供的。
虽然spy返回了解析的承诺，名言本身还没有到来。
Neither test can prove that a value from the service is displayed.
The quote itself has not arrived, despite the fact that the spy returns a resolved promise.
it('should show quote after getQuote promise (async)', async(()=>{
fixture.detectChanges();
fixture.whenStable().then(()=>{// wait for async getQuote
fixture.detectChanges();// update view with quote
expect(el.textContent).toBe(testQuote);});}));
The async function is one of the Angular testing utilities.
It simplifies coding of asynchronous tests by arranging for the tester's code to run in a special async test zone
as discussed earlier when it was called in a beforeEach.
Although async does a great job of hiding asynchronous boilerplate,
some functions called within a test (such as fixture.whenStable) continue to reveal their asynchronous behavior.
This test has no direct access to the promise returned by the call to twainService.getQuote
because it is buried inside TwainComponent.ngOnInit and therefore inaccessible to a test that
probes only the component API surface.
Fortunately, the getQuote promise is accessible to the async test zone ,
which intercepts all promises issued within the async method call no matter where they occur.
The ComponentFixture.whenStable method returns its own promise, which resolves when the getQuote promise finishes.
In fact, the whenStable promise resolves when all pending asynchronous activities within this test complete — the definition of "stable."
Then the test resumes and kicks off another round of change detection (fixture.detectChanges),
which tells Angular to update the DOM with the quote.
The getQuote helper method extracts the display element text and the expectation confirms that the text matches the test quote.
fakeAsync函数方法
The fakeAsync function
第四个测试程序用不同的方法验证同样的组件行为。
The fourth test verifies the same component behavior in a different way.
it('should show quote after getQuote promise (fakeAsync)', fakeAsync(()=>{
fixture.detectChanges();
tick();// wait for async getQuote
fixture.detectChanges();// update view with quote
expect(el.textContent).toBe(testQuote);}));
The principle advantage of fakeAsync over async is that the test appears to be synchronous.
There is no then(...) to disrupt the visible flow of control.
The promise-returning fixture.whenStable is gone, replaced by tick().
但是fakeAsync有局限性。比如，你不能从fakeAsync发起XHR请求。
There are limitations. For example, you cannot make an XHR call from within a fakeAsync.
Calling tick() simulates the passage of time until all pending asynchronous activities finish,
including the resolution of the getQuote promise in this test case.
Even this simple example is easier to read than the third test.
To more fully appreciate the improvement, imagine a succession of asynchronous operations,
chained in a long sequence of promise callbacks.
While the async and fakeAsync functions greatly
simplify Angular asynchronous testing,
you can still fall back to the traditional Jasmine asynchronous testing technique.
You can still pass it a function that takes a
done callback.
Now you are responsible for chaining promises, handling errors, and calling done at the appropriate moment.
it('should show quote after getQuote promise (done)',(done: any)=>{
fixture.detectChanges();// get the spy promise and wait for it to resolve
spy.calls.mostRecent().returnValue.then(()=>{
fixture.detectChanges();// update view with quote
expect(el.textContent).toBe(testQuote);done();});});
Although there is no direct access to the getQuote promise inside TwainComponent,
the spy has direct access, which makes it possible to wait for getQuote to finish.
Writing test functions with done, while more cumbersome than async
and fakeAsync, is a viable and occasionally necessary technique.
For example, you can't call async or fakeAsync when testing
code that involves the intervalTimer, as is common when
testing async Observable methods.
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.
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.
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.
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 async beforeEach was discussed above.
Having compiled the components asynchronously with compileComponents, the rest of the setup
proceeds synchronously in a secondbeforeEach, using the basic techniques described earlier.
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.
It verifies that the hero name is propagated to template with a binding.
Because the template passes the hero name through the Angular UpperCasePipe,
the test must match the element value with the uppercased name:
This small test demonstrates how Angular tests can verify a component's visual
representation—something not possible with
isolated unit tests—at
low cost and without resorting to much slower and more complicated end-to-end tests.
The second test verifies click behavior. Clicking the hero should raise a selected event that the
host component (DashboardComponent presumably) can hear:
The heroEl is a DebugElement that represents the hero <div>.
The test calls triggerEventHandler with the "click" event name.
The "click" event binding responds by calling DashboardHeroComponent.click().
If the component behaves as expected, click() tells the component's selected property to emit the hero object,
the test detects that value through its subscription to selected, and the test should pass.
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”事件。
In this example, the test triggers a "click" event with a null event object.
heroEl.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.
Other handlers are less forgiving. For example, the RouterLink
directive expects an object with a button property
that identifies which mouse button was pressed.
This directive throws an error if the event object doesn't do this correctly.
点击按钮、链接或者任意HTML元素是很常见的测试任务。
Clicking a button, an anchor, or an arbitrary HTML element is a common test task.
把click触发过程封装到辅助方法中可以简化这个任务，比如下面的click辅助方法：
Make that easy by encapsulating the click-triggering process in a helper such as the click function below:
testing/index.ts (click helper)
/** Button events to pass to `DebugElement.triggerEventHandler` for RouterLink event handler */exportconstButtonClickEvents={
left:{ button:0},
right:{ button:2}};/** Simulate element click. Defaults to mouse left-button click event. */exportfunction click(el:DebugElement|HTMLElement, eventObj: any =ButtonClickEvents.left):void{if(el instanceofHTMLElement){
el.click();}else{
el.triggerEventHandler('click', eventObj);}}
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测试工具click() is not an Angular testing utility
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 this click helper.
src/app/dashboard/dashboard-hero.component.spec.ts (click test revised)
In the previous approach, the tests themselves played the role of the host DashboardComponent.
But does the DashboardHeroComponent work correctly when properly data-bound to a host component?
Testing with the actual DashboardComponent host is doable but seems more trouble than its worth.
It's easier to emulate the DashboardComponent host with a test host like this one:
The test host binds to DashboardHeroComponent as the DashboardComponent would but without
the distraction of the Router, the HeroService, or even the *ngFor repeater.
The test host sets the component's hero input property with its test hero.
It binds the component's selected event with its onSelected handler,
which records the emitted hero
in its selectedHero property. Later, the tests check that property to verify that the
DashboardHeroComponent.selected event emitted the right hero.
配置使用测试宿主的测试程序与配置孤立测试相似：
The setup for the test-host tests is similar to the setup for the stand-alone tests:
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.nativeElement.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);});
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.
It also injects the HeroService, but faking that is a familiar story.
The Router has a complicated API and is entwined with other services and application preconditions.
幸运的是，DashbaordComponent没有使用Router做很多事情。
Fortunately, the DashboardComponent isn't doing much with the Router
This is often the case.
As a rule you test the component, not the router,
and care only if the component navigates with the right address under the given conditions.
Stubbing the router with a test implementation is an easy option. This should do the trick:
Now set up the testing module with the test stubs for the Router and HeroService, and
create a test instance of the DashboardComponent for subsequent testing.
src/app/dashboard/dashboard.component.spec.ts (compile and create)
it('should tell ROUTER to navigate when hero clicked',
inject([Router],(router:Router)=>{// ...const spy = spyOn(router,'navigateByUrl');
heroClick();// trigger click on first inner <div class="hero">// args passed to router.navigateByUrl()const navArgs = spy.calls.first().args[0];// expecting to navigate to id of the component's first heroconst id = comp.heroes[0].id;
expect(navArgs).toBe('/heroes/'+ id,'should nav to HeroDetail for first hero');}));
inject函数
The inject function
注意第二个it参数里面的inject函数。
Notice the inject function in the second it argument.
it('should tell ROUTER to navigate when hero clicked',
inject([Router],(router:Router)=>{// ...}));
inject函数是Angular测试工具之一。
它注入服务到测试函数，以供修改、监视和操纵。
The inject function is one of the Angular testing utilities.
It injects services into the test function where you can alter, spy on, and manipulate them.
inject函数有两个参数：
The inject function has two parameters:
一列数组，包含了Angular依赖注入令牌
An array of Angular dependency injection tokens.
一个测试函数，它的参数与注入令牌数组里的每个项目严格的一一对应。
A test function whose parameters correspond exactly to each item in the injection token array.
The inject function uses the current TestBed injector and can only return services provided at that level.
It does not return services from component providers.
This example injects the Router from the current TestBed injector.
That's fine for this test because the Router is, and must be, provided by the application root injector.
The inject function closes the current TestBed instance to further configuration.
You cannot call any more TestBed configuration methods, not configureTestingModule
nor any of the override... methods. The TestBed throws an error if you try.
不要在调用inject以后再试图配置TestBed。
Do not configure the TestBed after calling inject.
Clicking a Dashboard hero triggers navigation to heroes/:id, where :id
is a route parameter whose value is the id of the hero to edit.
That URL matches a route to the HeroDetailComponent.
The router pushes the :id token value into the ActivatedRoute.paramsObservable property,
Angular injects the ActivatedRoute into the HeroDetailComponent,
and the component extracts the id so it can fetch the corresponding hero via the HeroDetailService.
Here's the HeroDetailComponent constructor:
The expression after route.params chains an Observable operator that plucks the id from the params
and then chains a forEach operator to subscribe to id-changing events.
The id changes every time the user navigates to a different hero.
The forEach passes the new id value to the component's getHero method (not shown)
which fetches a hero and sets the component's hero property.
If theid parameter is missing, the pluck operator fails and the catch treats failure as a request to edit a new hero.
A test can explore how the HeroDetailComponent responds to different id parameter values
by manipulating the ActivatedRoute injected into the component's constructor.
By now you know how to stub the Router and a data service.
Stubbing the ActivatedRoute follows the same pattern except for a complication:
the ActivatedRoute.params is an Observable.
The hero-detail.component.spec.ts relies on an ActivatedRouteStub to set ActivatedRoute.params values for each test.
This is a cross-application, re-usable test helper class.
Consider placing such helpers in a testing folder sibling to the app folder.
This sample keeps ActivatedRouteStub in testing/router-stubs.ts:
testing/router-stubs.ts (ActivatedRouteStub)
import{BehaviorSubject}from'rxjs/BehaviorSubject';@Injectable()exportclassActivatedRouteStub{// ActivatedRoute.params is Observableprivate subject =newBehaviorSubject(this.testParams);params=this.subject.asObservable();// Test parametersprivate _testParams:{};get testParams(){returnthis._testParams;}set testParams(params:{}){this._testParams =params;this.subject.next(params);}// ActivatedRoute.snapshot.paramsget snapshot(){return{params:this.testParams };}}
Setting the testParams property causes the subject to push the assigned value into params.
That triggers the HeroDetailComponentparams subscription, described above, in the same way that navigation does.
设置testParams属性同时更新这个stub类内部值，用于snapshot属性的返回。
Setting the testParams property also updates the stub's internal value for the snapshot property to return.
When the id cannot be found, the component should re-route to the HeroListComponent.
The test suite setup provided the same RouterStubdescribed above which spies on the router without actually navigating.
This test supplies a "bad" id and expects the component to try to navigate.
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.
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:
src/app/hero/hero-detail.component.spec.ts (no id)
describe('when navigate with no hero id',()=>{
beforeEach( async( createComponent ));
it('should have hero.id === 0',()=>{
expect(comp.hero.id).toBe(0);});
it('should display empty hero name',()=>{
expect(page.nameDisplay.textContent).toBe('');});});
Tame the madness with a Page class that simplifies access to component properties and encapsulates the logic that sets them.
Here's the Page class for the hero-detail.component.spec.ts
src/app/hero/hero-detail.component.spec.ts (Page)
classPage{
gotoSpy: jasmine.Spy;
navSpy: jasmine.Spy;
saveBtn:DebugElement;
cancelBtn:DebugElement;
nameDisplay:HTMLElement;
nameInput:HTMLInputElement;
constructor(){const router =TestBed.get(Router);// get router from root injectorthis.gotoSpy = spyOn(comp,'gotoList').and.callThrough();this.navSpy = spyOn(router,'navigate');}/** Add page elements after hero arrives */
addPageElements(){if(comp.hero){// have a hero so these elements are now in the DOMconst buttons = fixture.debugElement.queryAll(By.css('button'));this.saveBtn = buttons[0];this.cancelBtn = buttons[1];this.nameDisplay = fixture.debugElement.query(By.css('span')).nativeElement;this.nameInput = fixture.debugElement.query(By.css('input')).nativeElement;}}}
现在，用来操作和检查组件的重要钩子都被井然有序的组织起来了，可以通过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 objectand fills in the blanks once the hero arrives.
The observable tests in the previous section demonstrate how createComponent and page
keep the tests short and on message.
There are no distractions: no waiting for promises to resolve and no searching the DOM for element values to compare.
这里是一些更多的HeroDetailComponent测试程序，进一步的展示了这一点。
Here are a few more HeroDetailComponent tests to drive the point home.
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.navSpy.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.navSpy.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.navSpy.calls.any()).toBe(true,'router.navigate called');}));
it('should convert hero name to Title Case',()=>{const inputName ='quick BROWN fox';const titleCaseName ='Quick Brown Fox';// simulate user entering new name into the input box
page.nameInput.value = inputName;// dispatch a DOM event so that Angular learns of input value change.
page.nameInput.dispatchEvent(newEvent('input'));// Tell Angular to update the output span through the title pipe
fixture.detectChanges();
expect(page.nameDisplay.textContent).toBe(titleCaseName);});
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.
Fortunately, the TestBed.configureTestingModule parameter parallels
the metadata passed to the @NgModule decorator
which means you can also specify providers and imports.
The HeroDetailComponent requires a lot of help despite its small size and simple construction.
In addition to the support it receives from the default testing module CommonModule, it needs:
FormsModule里的NgModel和其它，来进行双向数据绑定
NgModel and friends in the FormsModule to enable two-way data binding.
shared目录里的TitleCasePipe
The TitleCasePipe from the shared 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:
Because many app components need the FormsModule and the TitleCasePipe, the developer created
a SharedModule to combine these and other frequently requested parts.
The test configuration can use the SharedModule too as seen in this alternative setup:
The HeroDetailComponent is part of the HeroModuleFeature Module that aggregates more of the interdependent pieces
including the SharedModule.
Try a test configuration that imports the HeroModule like this one:
In fact, if you try to declare it, Angular throws an error because
HeroDetailComponent is declared in both the HeroModule and the DynamicTestModule (the testing module).
Importing the component's feature module is often the easiest way to configure the tests,
especially when the feature module is small and mostly self-contained, as feature modules should be.
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 creates the component with its own injector, which is a child of the fixture injector.
It registers the component's providers (the HeroDetailService in this case) with the child injector.
A test cannot get to child injector services from the fixture injector.
And TestBed.configureTestingModule can't configure them either.
Angular始终都在创建真实HeroDetailService的实例。
Angular has been creating new instances of the real HeroDetailService all along!
It takes two arguments: the component type to override (HeroDetailComponent) and an override metadata object.
The overide metadata object is a generic defined as follows:
type MetadataOverride={
add?: T;
remove?: T;set?: T;};
A metadata override object can either add-and-remove elements in metadata properties or completely reset those properties.
This example resets the component's providers metadata.
这个类型参数，T，是你会传递给@Component装饰器的元数据的类型。
The type parameter, T, is the kind of metadata you'd pass to the @Component decorator:
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.
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:
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(comp.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.navSpy.calls.any()).toBe(true,'router.navigate called');}));
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.
The component stubs are essential.
Without them, the Angular compiler doesn't recognize the <app-welcome> and <router-outlet> tags
and throws an error.
Stub伪造RouterLink
Stubbing the RouterLink
RouterLinkStubDirective为测试作出了重要的贡献：
The RouterLinkStubDirective contributes substantively to the test:
testing/router-stubs.ts (RouterLinkStubDirective)
@Directive({
selector:'[routerLink]',
host:{'(click)':'onClick()'}})exportclassRouterLinkStubDirective{@Input('routerLink') linkParams: any;
navigatedTo: any =null;
onClick(){this.navigatedTo =this.linkParams;}}
The host metadata property wires the click event of the host element (the <a>) to the directive's onClick method.
The URL bound to the [routerLink] attribute flows to the directive's linkParams property.
Clicking the anchor should trigger the onClick method which sets the telltale navigatedTo property.
Tests can inspect that property to confirm the expected click-to-navigation behavior.
By.directive和注入的指令
By.directive and injected directives
再一步配置触发了数据绑定的初始化，获取导航链接的引用：
A little more setup triggers the initial data binding and gets references to the navigation links:
src/app/app.component.spec.ts (test setup)
beforeEach(()=>{// trigger initial data binding
fixture.detectChanges();// find DebugElements with an attached RouterLinkStubDirective
linkDes = fixture.debugElement
.queryAll(By.directive(RouterLinkStubDirective));// get the attached link directive instances using the DebugElement injectors
links = linkDes
.map(de => de.injector.get(RouterLinkStubDirective)asRouterLinkStubDirective);});
特别值得注意的两点：
Two points of special interest:
你还可以按指令定位元素，使用By.directive，而不仅仅是通过CSS选择器。
You can locate elements by directive, using By.directive, not just by css selectors.
你可以使用组件的依赖注入器来获取附加的指令，因为Angular总是将附加组件添加到组件的注入器中。
You can use the component's dependency injector to get an attached directive because
Angular always adds attached directives to the component's injector.
下面是一些使用这个配置的测试程序：
Here are some tests that leverage this setup:
src/app/app.component.spec.ts (selected tests)
it('can get RouterLinks from template',()=>{
expect(links.length).toBe(3,'should have 3 links');
expect(links[0].linkParams).toBe('/dashboard','1st link should go to Dashboard');
expect(links[1].linkParams).toBe('/heroes','1st link should go to Heroes');});
it('can click Heroes link in template',()=>{const heroesLinkDe = linkDes[1];const heroesLink = links[1];
expect(heroesLink.navigatedTo).toBeNull('link should not have navigated yet');
heroesLinkDe.triggerEventHandler('click',null);
fixture.detectChanges();
expect(heroesLink.navigatedTo).toBe('/heroes');});
The "click" test in this example is worthless.
It works hard to appear useful when in fact it
tests the RouterLinkStubDirective rather than the component.
This is a common failing of directive stubs.
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.
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.
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.
Without them, the Angular compiler doesn't recognize the <app-banner>, <app-welcome> and <router-outlet> tags
in the app.component.html template and throws an error.
Add NO_ERRORS_SCHEMA to the testing module's schemas metadata
to tell the compiler to ignore unrecognized elements and attributes.
You no longer have to declare irrelevant components and directives.
These tests are shallow because they only "go deep" into the components you want to test.
Here is a setup, with import statements, that demonstrates the improved simplicity of shallow tests, relative to the stubbing setup.
The only declarations are the component-under-test (AppComponent) and the RouterLinkStubDirective
that contributes actively to the tests.
The tests in this example are unchanged.
Shallow component tests with NO_ERRORS_SCHEMA greatly simplify unit testing of complex templates.
However, the compiler no longer alerts you to mistakes
such as misspelled or misused components and directives.
An attribute directive modifies the behavior of an element, component or another directive.
Its name reflects the way the directive is applied: as an attribute on a host element.
The sample application's HighlightDirective sets the background color of an element
based on either a data bound color or a default color (lightgray).
It also sets a custom property of the element (customProperty) to true
for no reason other than to show that it can.
src/app/shared/highlight.directive.ts
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 */exportclassHighlightDirectiveimplementsOnChanges{
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:
src/app/about.component.ts
import{Component}from'@angular/core';@Component({template:`
<h2 highlight="skyblue">About</h2>
<twain-quote></twain-quote>
<p>All about this sample</p>`})exportclassAboutComponent{}
Testing the specific use of the HighlightDirective within the AboutComponent requires only the
techniques explored above (in particular the "Shallow test" approach).
However, testing a single use case is unlikely to explore the full range of a directive's capabilities.
Finding and testing all components that use the directive is tedious, brittle, and almost as unlikely to afford full coverage.
Isolated unit tests might be helpful,
but attribute directives like this one tend to manipulate the DOM.
Isolated unit tests don't touch the DOMand, therefore ,
do not inspire confidence in the directive's efficacy.
更好的方法是创建一个展示所有使用该组件的方法的人工测试组件。
A better solution is to create an artificial test component that demonstrates all ways to apply the directive.
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.
The :not pseudo-class
in By.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 affords access to element styles even in the absence of a real browser, thanks to the DebugElement abstraction.
But feel free to exploit the nativeElement when that seems easier or more clear than the abstraction.
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 its HighlightDirective instance
and its defaultColor.
DebugElement.properties让我们可以访问由指令设置的自定义属性。
DebugElement.properties affords access to the artificial custom property that is set by the directive.
However, it's often more productive to explore the inner logic of application classes
with isolated unit tests that don't depend upon Angular.
Such tests are often smaller and easier to read, write, and maintain.
它们不用背负额外的包袱：
They don't carry extra baggage:
从Angular测试库导入
Import from the Angular test libraries.
配置模块
Configure a module.
准备依赖注入providers
Prepare dependency injection providers.
调用inject，或者async，或者fakeAsync
Call inject or async or fakeAsync.
它们会遵循测试时众所周知的模式：
They follow patterns familiar to test developers everywhere:
Good developers write both kinds of tests for the same application part, often in the same spec file.
Write simple isolated unit tests to validate the part in isolation.
Write Angular tests to validate the part as it interacts with Angular,
updates the DOM, and collaborates with the rest of the application.
Services are good candidates for isolated unit testing.
Here are some synchronous and asynchronous unit tests of the FancyService
written without assistance from Angular testing utilities.
src/app/bag/bag.no-testbed.spec.ts
// Straight Jasmine - no imports from Angular test libraries
describe('FancyService without the TestBed',()=>{
let service:FancyService;
beforeEach(()=>{ service =newFancyService();});
it('#getValue should return real value',()=>{
expect(service.getValue()).toBe('real value');
});
it('#getAsyncValue should return async value',(done:DoneFn)=>{
service.getAsyncValue().then(value =>{
expect(value).toBe('async value');
done();
});
});
it('#getTimeoutValue should return timeout value',(done:DoneFn)=>{
service =newFancyService();
service.getTimeoutValue().then(value =>{
expect(value).toBe('timeout value');
done();
});
});
it('#getObservableValue should return observable value',(done:DoneFn)=>{
A rough line count suggests that these isolated unit tests are about 25% smaller than equivalent Angular tests.
That's telling but not decisive.
The benefit comes from reduced setup and code complexity.
比较下面两个同等的FancyService.getTimeoutValue测试程序：
Compare these equivalent tests of FancyService.getTimeoutValue.
it('#getTimeoutValue should return timeout value',(done:DoneFn)=>{
They have about the same line-count, but the Angular-dependent version
has more moving parts including a couple of utility functions (async and inject).
Both approaches work and it's not much of an issue if you're using the
Angular testing utilities nearby for other reasons.
On the other hand, why burden simple service tests with added complexity?
Services often depend on other services that Angular injects into the constructor.
You can test these services without the TestBed.
In many cases, it's easier to create and inject dependencies by hand.
However, it's rarely that simple. The injected service can be difficult to create or control.
You can mock the dependency, use a dummy value, or stub the pertinent service method
with a substitute method that 's easy to control.
These isolated unit testing techniques are great for exploring the inner logic of a service or its
simple integration with a component class.
Use the Angular testing utilities when writing tests that validate how a service interacts with components
within the Angular runtime environment.
管道
Pipes
管道很容易测试，无需Angular测试工具。
Pipes are easy to test without the Angular testing utilities.
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.
Consider a TitleCasePipe that capitalizes the first letter of each word.
Here's a naive implementation with a regular expression.
src/app/shared/title-case.pipe.ts
import{Pipe,PipeTransform}from'@angular/core';@Pipe({name:'titlecase', pure:false})/** Transform to Title Case: uppercase the first letter of the words in a string.*/exportclassTitleCasePipeimplementsPipeTransform{
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.
src/app/shared/title-case.pipe.spec.ts
describe('TitleCasePipe',()=>{
// This pipe is a pure, stateless function so no need for BeforeEach
Component tests typically examine how a component class interacts with its own template or with collaborating components.
The Angular testing utilities are specifically designed to facilitate such tests.
考虑这个ButtonComp组件。
Consider this ButtonComp component.
src/app/bag/bag.ts (ButtonComp)
@Component({
selector:'button-comp',template:`
<button (click)="clicked()">Click me!</button>
<span>{{message}}</span>`})exportclassButtonComponent{
isOn =false;
clicked(){this.isOn =!this.isOn;}get message(){return`The light is ${this.isOn ? 'On' : 'Off'}`;}}
下面的Angular测试演示点击模板里的按钮后，引起了屏幕上的消息的更新。
The following Angular test demonstrates that clicking a button in the template leads
to an update of the on-screen message.
The assertions verify that the data values flow from one HTML control (the <button>) to the component and
from the component back to a different HTML control (the <span>).
A passing test means the component and its template are wired correctly.
孤立单元测试可以更快的在API边界探测组件，更轻松的探索更多条件。
Isolated unit tests can more rapidly probe a component at its API boundary,
exploring many more conditions with less effort.
下面是一套单元测试程序，用来验证面对多种输入时组件的输出。
Here are a set of unit tests that verify the component's outputs in the face of a variety of
component inputs.
src/app/bag/bag.no-testbed.spec.ts (ButtonComp)
describe('ButtonComp',()=>{let comp:ButtonComponent;
beforeEach(()=> comp =newButtonComponent());
it('#isOn should be false initially',()=>{
expect(comp.isOn).toBe(false);});
it('#clicked() should set #isOn to true',()=>{
comp.clicked();
expect(comp.isOn).toBe(true);});
it('#clicked() should set #message to "is on"',()=>{
comp.clicked();
expect(comp.message).toMatch(/is on/i);});
it('#clicked() should toggle #isOn',()=>{
comp.clicked();
expect(comp.isOn).toBe(true);
comp.clicked();
expect(comp.isOn).toBe(false);});});
Isolated component tests offer a lot of test coverage with less code and almost no setup.
This is even more of an advantage with complex components, which
may require meticulous preparation with the Angular testing utilities.
On the other hand, isolated unit tests can't confirm that the ButtonComp is
properly bound to its template or even data bound at all.
Use Angular tests for that.
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:
Runs the body of a test (it) within a special fakeAsync test zone, enabling
a linear control flow coding style. See discussion above.
tick
在fakeAsync测试区域内触发计时器和微任务队列，以模拟时间的推移和未完成异步任务的完成。
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.
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.
In general, a test should end with no queued tasks.
When pending timer tasks are expected, call discardPeriodicTasks to flush the task queue
and avoid the error.
In general, a test should wait for micro-tasks to finish.
When pending microtasks are expected, call flushMicrotasks to flush the micro-task queue
and avoid the error.
Gets the current instance of the TestBed.
Usually unnecessary because the static class methods of the TestBed class are typically sufficient.
The TestBed instance exposes a few rarely used members that are not available as
static methods.
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[]>;};
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?: T;
remove?: T;set?: T;};
TestBed的API包含了一系列静态类方法，它们更新或者引用全局的TestBed实例。
The TestBed API consists of static class methods that either update or reference a global instance of theTestBed.
The testing shims (karma-test-shim, browser-test-shim)
establish the initial test environment and a default testing module.
The default testing module is configured with basic declaratives and some Angular service substitutes that every tester needs.
Call configureTestingModule to refine the testing module configuration for a particular set of tests
by adding and removing imports, declarations (of components, directives, and pipes), and providers.
Compile the testing module asynchronously after you've finished configuring it.
You must call this method if any of the testing module components have a templateUrl
or styleUrls because fetching component template and style files is necessarily asynchronous.
See above.
调用完compileComponents之后，TestBed的配置就会在当前测试期间被冻结。
After calling compileComponents, the TestBed configuration is frozen for the duration of the current spec.
Create an instance of a component of type T based on the current TestBed configuration.
After calling compileComponent, the TestBed configuration is frozen for the duration of the current spec.
Replace metadata for the given NgModule. Recall that modules can import other modules.
The overrideModule method can reach deeply into the current testing module to
modify one of these inner modules.
overrideComponent
替换指定组件类的元数据，该组件类可能嵌套在一个很深的内部模块中。
Replace metadata for the given component class, which could be nested deeply
within an inner module.
overrideDirective
替换指定指令类的元数据，该指令可能嵌套在一个很深的内部模块中。
Replace metadata for the given directive class, which could be nested deeply
within an inner module.
overridePipe
替换指定管道类的元数据，该管道可能嵌套在一个很深的内部模块中。
Replace metadata for the given pipe class, which could be nested deeply
within an inner module.
get
从当前TestBed注入器获取一个服务。
Retrieve a service from the current TestBed injector.
Specify the Angular compiler factory, a PlatformRef, and a default Angular testing module.
Alternatives for non-browser platforms are available in the general form
@angular/platform-<platform_name>/testing/<platform_name>.
resetTestEnvironment
重设初始测试环境，包括默认测试模块在内。
Reset the initial test environment, including the default testing module.
少数TestBed实例方法没有对应的静态方法。它们很少被使用。
A few of the TestBed instance methods are not covered by static TestBedclass methods.
These are rarely needed.
The debugElement provides insight into the component and its DOM element during test and debugging.
It's a critical property for testers. The most interesting members are covered below.
nativeElement
组件的原生根DOM元素。
The native DOM element at the root of the component.
The ChangeDetectorRef is most valuable when testing a
component that has the ChangeDetectionStrategy.OnPush method
or the component's change detection is under your programmatic control.
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
detectChanges
为组件触发一轮变化检查。
Trigger a change detection cycle for the component.
Call it to initialize the component (it calls ngOnInit) and after your
test code, change the component's data bound property values.
Angular can't see that you've changed personComponent.name and won't update the name
binding until you call detectChanges.
When autodetect is true, the test fixture calls detectChanges immediately
after creating the component. Then it listens for pertinent zone events
and calls detectChanges accordingly.
When your test code modifies component property values directly,
you probably still have to call fixture.detectChanges to trigger data binding updates.
默认值是false，喜欢对测试行为进行精细控制的测试者一般保持它为false。
The default is false. Testers who prefer fine control over test behavior
tend to keep it false.
checkNoChanges
运行一次变更检测来确认没有待处理的变化。如果有未处理的变化，它将抛出一个错误。
Do a change detection run to make sure there are no pending changes.
Throws an exceptions if there are.
isStable
如果fixture当前是稳定的，则返回true。
如果有异步任务没有完成，则返回false。
If the fixture is currently stable, returns true.
If there are async tasks that have not completed, returns false.
whenStable
返回一个承诺，在fixture稳定时解析。
Returns a promise that resolves when the fixture is stable.
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
nativeElement
与浏览器中DOM元素对应（WebWorkers时，值为null）。
The corresponding DOM element in the browser (null for WebWorkers).
Calling queryAll(predicate: Predicate<DebugElement>) returns all DebugElements
that matches the predicate at any depth in subtree.
injector
宿主依赖注入器。
比如，根元素的组件实例注入器。
The host dependency injector.
For example, the root element's component instance injector.
componentInstance
元素自己的组件实例（如果有）。
The element's own component instance, if it has one.
context
为元素提供父级上下文的对象。
通常是控制该元素的祖级组件实例。
An object that provides parent context for this element.
Often an ancestor component instance that governs this element.
当一个元素被*ngFor重复，它的上下文为NgForRow，它的$implicit属性值是该行的实例值。
比如，*ngFor="let hero of heroes"里的hero。
When an element is repeated within *ngFor, the context is an NgForRow whose $implicit
property is the value of the row instance value.
For example, the hero in *ngFor="let hero of heroes".
children
DebugElement的直接子级。通过children来降序探索元素树。
The immediate DebugElement children. Walk the tree by descending through children.
DebugElement also has childNodes, a list of DebugNode objects.
DebugElement derives from DebugNode objects and there are often
more nodes than elements. Testers can usually ignore plain nodes.
parent
DebugElement的父级。如果DebugElement是根元素，parent为null。
The DebugElement parent. Null if this is the root element.
Triggers the event by its name if there is a corresponding listener
in the element's listeners collection.
The second parameter is the event object expected by the handler.
See above.
The DebugElement.query(predicate) and DebugElement.queryAll(predicate) methods take a
predicate that filters the source element's subtree for matching 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 referenceconst 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) - return elements that Angular matched to an instance of the directive class.
src/app/hero/hero-list.component.spec.ts
// Can find DebugElement either by css selector or by directiveconst h2 = fixture.debugElement.query(By.css('h2'));const directive = fixture.debugElement.query(By.directive(HighlightDirective));
it('BankAccountComponent should set attributes, styles, classes, and properties',()=>{const fixture =TestBed.createComponent(BankAccountParentComponent);
fixture.detectChanges();const comp = fixture.componentInstance;// the only child is debugElement of the BankAccount componentconst el = fixture.debugElement.children[0];const childComp = el.componentInstance asBankAccountComponent;
expect(childComp).toEqual(jasmine.any(BankAccountComponent));
expect(el.context).toBe(childComp,'context is the child component');
expect(el.attributes['account']).toBe(childComp.id,'account attribute');
expect(el.attributes['bank']).toBe(childComp.bank,'bank attribute');
expect(el.classes['closed']).toBe(true,'closed class');
expect(el.classes['open']).toBe(false,'open class');
expect(el.styles['color']).toBe(comp.color,'color style');
expect(el.styles['width']).toBe(comp.width +'px','width style');});
Unit testing requires some configuration and bootstrapping that is captured in setup files.
The setup files for this guide are provided for you when you follow the Setup instructions.
The CLI delivers similar files with the same purpose.
下面是对本章中这些设置文件的简短说明：
Here's a brief description of this guide's setup files:
本章不会深入讲解这些文件的详情以及如何根据需要重新配置它们，那超出了本章的范围。
The deep details of these files and how to reconfigure them for your needs
is a topic beyond the scope of this guide .
The karma configuration file that specifies which plug-ins to use,
which application and test files to load, which browser(s) to use,
and how to report test results.
This shim prepares karma specifically for the Angular test environment
and launches karma itself.
It loads the systemjs.config.js file as part of that process.
SystemJS
loads the application and test files.
This script tells SystemJS where to find those files and how to load them.
It's the same version of systemjs.config.js you installed during setup.
An optional file that supplements the SystemJS configuration in systemjs.config.js with
configuration for the specific needs of the application itself.
常规的systemjs.config.js文件无法满足那些需求，我们需要自己填充它。
A stock systemjs.config.js can't anticipate those needs.
You fill the gaps here.
本章的例子中把*模型桶（barrel）添加到了SystemJS的packages配置中。
The sample version for this guide adds the model barrel
to the SystemJs packages configuration.
systemjs.config.extras.js
/** App specific SystemJS configuration */System.config({
packages:{// barrels'app/model':{main:'index.js', defaultExtension:'js'},'app/model/testing':{main:'index.js', defaultExtension:'js'}}});
The sample tests are written to run in Jasmine and karma.
The two "fast path" setups added the appropriate Jasmine and karma npm packages to the
devDependencies section of the package.json.
They're installed when you run npm install.
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.
