iSharkFly-Docs
/
angular-docs-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: break testing doc into multiple docs (#37957) 

This commit breaks up the testing document into nine total documents, with each document focusing on an existing section of the current testing documentation. There are no content changes.

PR Close #37957
This commit is contained in:
Kapunahele Wong 2020-06-30 14:14:34 -04:00 committed by atscott
parent f81d3f6199
commit bdbbff6a1a
12 changed files with 3537 additions and 3429 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
.pullapprove.yml
View File

@ -612,6 +612,14 @@ groups:
contains_any_globs(files.exclude('packages/compiler-cli/**'), [
'**/testing/**',
'aio/content/guide/testing.md',
'aio/content/guide/test-debugging.md',
'aio/content/guide/testing-attribute-directives.md',
'aio/content/guide/testing-code-coverage.md',
'aio/content/guide/testing-components-basics.md',
'aio/content/guide/testing-components-scenarios.md',
'aio/content/guide/testing-pipes.md',
'aio/content/guide/testing-services.md',
'aio/content/guide/testing-utility-apis.md',
'aio/content/examples/testing/**',
'aio/content/images/guide/testing/**'
])

28
aio/content/guide/test-debugging.md Normal file
View File

@ -0,0 +1,28 @@
# Debugging tests
If your tests aren't working as you expect them to, you can inspect and debug them in the browser.
<div class="alert is-helpful">
For the sample app that the testing guides describe, see the <live-example embedded-style noDownload>sample app</live-example>.
For the tests features in the testing guides, see <live-example stackblitz="specs" noDownload>tests</live-example>.
</div>
Debug specs in the browser in the same way that you debug an application.
1. Reveal the Karma browser window. See [Set up testing](guide/testing#set-up-testing) if you need help with this step.
1. Click the **DEBUG** button; it opens a new browser tab and re-runs the tests.
1. Open the browser's “Developer Tools” (`Ctrl-Shift-I` on Windows; `Command-Option-I` in macOS).
1. Pick the "sources" section.
1. Open the `1st.spec.ts` test file (Control/Command-P, then start typing the name of the file).
1. Set a breakpoint in the test.
1. Refresh the browser, and it stops at the breakpoint.
<div class="lightbox">
<img src='generated/images/guide/testing/karma-1st-spec-debug.png' alt="Karma debugging">
</div>
<hr>

78
aio/content/guide/testing-attribute-directives.md Normal file
View File

@ -0,0 +1,78 @@
{@a attribute-directive}
# Testing Attribute 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.
<div class="alert is-helpful">
For the sample app that the testing guides describe, see the <live-example embedded-style noDownload>sample app</live-example>.
For the tests features in the testing guides, see <live-example stackblitz="specs" noDownload>tests</live-example>.
</div>
## Testing the `HighlightDirective`
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.
<code-example path="testing/src/app/shared/highlight.directive.ts" header="app/shared/highlight.directive.ts"></code-example>
It's used throughout the application, perhaps most simply in the `AboutComponent`:
<code-example path="testing/src/app/about/about.component.ts" header="app/about/about.component.ts"></code-example>
Testing the specific use of the `HighlightDirective` within the `AboutComponent` requires only the techniques explored in the ["Nested component tests"](guide/testing-components-scenarios#nested-component-tests) section of [Component testing scenarios](guide/testing-components-scenarios).
<code-example path="testing/src/app/about/about.component.spec.ts" region="tests" header="app/about/about.component.spec.ts"></code-example>
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.
_Class-only tests_ might be helpful,
but attribute directives like this one tend to manipulate the DOM.
Isolated unit tests don't touch the DOM and, therefore,
do not inspire confidence in the directive's efficacy.
A better solution is to create an artificial test component that demonstrates all ways to apply the directive.
<code-example path="testing/src/app/shared/highlight.directive.spec.ts" region="test-component" header="app/shared/highlight.directive.spec.ts (TestComponent)"></code-example>
<div class="lightbox">
<img src='generated/images/guide/testing/highlight-directive-spec.png' alt="HighlightDirective spec in action">
</div>
<div class="alert is-helpful">
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.
</div>
Here are some tests of this component:
<code-example path="testing/src/app/shared/highlight.directive.spec.ts" region="selected-tests" header="app/shared/highlight.directive.spec.ts (selected tests)"></code-example>
A few techniques are noteworthy:
- The `By.directive` predicate is a great way to get the elements that have this directive _when their element types are unknown_.
- The <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/:not">`:not` pseudo-class</a>
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` affords access to the artificial custom property that is set by the directive.
<hr>

57
aio/content/guide/testing-code-coverage.md Normal file
View File

@ -0,0 +1,57 @@
{@a code-coverage}
# Find out how much code you're testing
The CLI can run unit tests and create code coverage reports.
Code coverage reports show you any parts of your code base that may not be properly tested by your unit tests.
<div class="alert is-helpful">
For the sample app that the testing guides describe, see the <live-example embedded-style noDownload>sample app</live-example>.
For the tests features in the testing guides, see <live-example stackblitz="specs" noDownload>tests</live-example>.
</div>
To generate a coverage report run the following command in the root of your project.
<code-example language="sh" class="code-shell">
ng test --no-watch --code-coverage
</code-example>
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.
If you want to create code-coverage reports every time you test, you can set the following option in the CLI configuration file, `angular.json`:
```
"test": {
"options": {
"codeCoverage": true
}
}
```
## Code coverage enforcement
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.
For example, suppose you want the code base to have a minimum of 80% code coverage.
To enable this, open the [Karma](https://karma-runner.github.io) test platform configuration file, `karma.conf.js`, and add the following in the `coverageIstanbulReporter:` key.
```
coverageIstanbulReporter: {
reports: [ 'html', 'lcovonly' ],
fixWebpackSourcePaths: true,
thresholds: {
statements: 80,
lines: 80,
branches: 80,
functions: 80
}
}
```
The `thresholds` property causes the tool to enforce a minimum of 80% code coverage when the unit tests are run in the project.

380
aio/content/guide/testing-components-basics.md Normal file
View File

@ -0,0 +1,380 @@
# Basics of testing components
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_. To adequately test a component, you should test that they work together
as intended.
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.
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.
<div class="alert is-helpful">
For the sample app that the testing guides describe, see the <live-example embedded-style noDownload>sample app</live-example>.
For the tests features in the testing guides, see <live-example stackblitz="specs" noDownload>tests</live-example>.
</div>
{@a component-class-testing}
## Component class testing
Test a component class on its own as you would test a service class.
Component class testing should be kept very clean and simple.
It should test only a single unit.
At first glance, you should be able to understand
what the test is testing.
Consider this `LightswitchComponent` which toggles a light on and off
(represented by an on-screen message) when the user clicks the button.
<code-example
path="testing/src/app/demo/demo.ts"
region="LightswitchComp"
header="app/demo/demo.ts (LightswitchComp)"></code-example>
You might decide only to test that the `clicked()` method
toggles the light's _on/off_ state and sets the message appropriately.
This component class has no dependencies. To test these types of classes, follow the same steps as you would for a service that has no dependencies:
1. Create a component using the new keyword.
2. Poke at its API.
3. Assert expectations on its public state.
<code-example
path="testing/src/app/demo/demo.spec.ts"
region="Lightswitch"
header="app/demo/demo.spec.ts (Lightswitch tests)"></code-example>
Here is the `DashboardHeroComponent` from the _Tour of Heroes_ tutorial.
<code-example
path="testing/src/app/dashboard/dashboard-hero.component.ts"
region="class"
header="app/dashboard/dashboard-hero.component.ts (component)"></code-example>
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.
You can test that the class code works without creating the `DashboardHeroComponent`
or its parent component.
<code-example
path="testing/src/app/dashboard/dashboard-hero.component.spec.ts"
region="class-only"
header="app/dashboard/dashboard-hero.component.spec.ts (class tests)"></code-example>
When a component has dependencies, you may wish to use the `TestBed` to both
create the component and its dependencies.
The following `WelcomeComponent` depends on the `UserService` to know the name of the user to greet.
<code-example
path="testing/src/app/welcome/welcome.component.ts"
region="class"
header="app/welcome/welcome.component.ts"></code-example>
You might start by creating a mock of the `UserService` that meets the minimum needs of this component.
<code-example
path="testing/src/app/welcome/welcome.component.spec.ts"
region="mock-user-service"
header="app/welcome/welcome.component.spec.ts (MockUserService)"></code-example>
Then provide and inject _both the_ **component** _and the service_ in the `TestBed` configuration.
<code-example
path="testing/src/app/welcome/welcome.component.spec.ts"
region="class-only-before-each"
header="app/welcome/welcome.component.spec.ts (class-only setup)"></code-example>
Then exercise the component class, remembering to call the [lifecycle hook methods](guide/lifecycle-hooks) as Angular does when running the app.
<code-example
path="testing/src/app/welcome/welcome.component.spec.ts"
region="class-only-tests"
header="app/welcome/welcome.component.spec.ts (class-only tests)"></code-example>
## Component DOM testing
Testing the component _class_ is as easy as [testing a service](guide/testing-services).
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.
- Is `Lightswitch.clicked()` bound to anything such that the user can invoke it?
- Is the `Lightswitch.message` displayed?
- Can the user actually select the hero displayed by `DashboardHeroComponent`?
- Is the hero name displayed as expected (i.e, in uppercase)?
- Is the welcome message displayed by the template of `WelcomeComponent`?
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.
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.
To write these kinds of test, you'll use additional features of the `TestBed`
as well as other testing helpers.
### CLI-generated tests
The CLI creates an initial test file for you by default when you ask it to
generate a new component.
For example, the following CLI command generates a `BannerComponent` in the `app/banner` folder (with inline template and styles):
<code-example language="sh" class="code-shell">
ng generate component banner --inline-template --inline-style --module app
</code-example>
It also generates an initial test file for the component, `banner-external.component.spec.ts`, that looks like this:
<code-example
path="testing/src/app/banner/banner-initial.component.spec.ts"
region="v1"
header="app/banner/banner-external.component.spec.ts (initial)"></code-example>
<div class="alert is-helpful">
Because `compileComponents` is asynchronous, it uses
the [`async`](api/core/testing/async) utility
function imported from `@angular/core/testing`.
Please refer to the [async](guide/testing-components-scenarios#async) section for more details.
</div>
### Reduce the setup
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:
<code-example
path="testing/src/app/banner/banner-initial.component.spec.ts"
region="v2"
header="app/banner/banner-initial.component.spec.ts (minimal)"></code-example>
In this example, the metadata object passed to `TestBed.configureTestingModule`
simply declares `BannerComponent`, the component to test.
<code-example
path="testing/src/app/banner/banner-initial.component.spec.ts"
region="configureTestingModule">
</code-example>
<div class="alert is-helpful">
There's no need to declare or import anything else.
The default test module is pre-configured with
something like the `BrowserModule` from `@angular/platform-browser`.
Later you'll call `TestBed.configureTestingModule()` with
imports, providers, and more declarations to suit your testing needs.
Optional `override` methods can further fine-tune aspects of the configuration.
</div>
{@a create-component}
### _createComponent()_
After configuring `TestBed`, you call its `createComponent()` method.
<code-example
path="testing/src/app/banner/banner-initial.component.spec.ts"
region="createComponent">
</code-example>
`TestBed.createComponent()` creates an instance of the `BannerComponent`,
adds a corresponding element to the test-runner DOM,
and returns a [`ComponentFixture`](#component-fixture).
<div class="alert is-important">
Do not re-configure `TestBed` after calling `createComponent`.
The `createComponent` method freezes the current `TestBed` definition,
closing it to further configuration.
You cannot call any more `TestBed` configuration methods, not `configureTestingModule()`,
nor `get()`, nor any of the `override...` methods.
If you try, `TestBed` throws an error.
</div>
{@a component-fixture}
### _ComponentFixture_
The [ComponentFixture](api/core/testing/ComponentFixture) is a test harness for interacting with the created component and its corresponding element.
Access the component instance through the fixture and confirm it exists with a Jasmine expectation:
<code-example
path="testing/src/app/banner/banner-initial.component.spec.ts"
region="componentInstance">
</code-example>
### _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:
<code-example
path="testing/src/app/banner/banner-initial.component.spec.ts"
region="v3"
></code-example>
Now add a test that gets the component's element from `fixture.nativeElement` and
looks for the expected text.
<code-example
path="testing/src/app/banner/banner-initial.component.spec.ts"
region="v4-test-2">
</code-example>
{@a native-element}
### _nativeElement_
The value of `ComponentFixture.nativeElement` has the `any` type.
Later you'll encounter the `DebugElement.nativeElement` and it too has the `any` type.
Angular can't know at compile time what kind of HTML element the `nativeElement` is or
if it even is an HTML element.
The app might be running on a _non-browser platform_, such as the server or a
[Web Worker](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API),
where the element may have a diminished API or not exist at all.
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.
Knowing that it is an `HTMLElement` of some sort, you can use
the standard HTML `querySelector` to dive deeper into the element tree.
Here's another test that calls `HTMLElement.querySelector` to get the paragraph element and look for the banner text:
<code-example
path="testing/src/app/banner/banner-initial.component.spec.ts"
region="v4-test-3">
</code-example>
{@a debug-element}
### _DebugElement_
The Angular _fixture_ provides the component's element directly through the `fixture.nativeElement`.
<code-example
path="testing/src/app/banner/banner-initial.component.spec.ts"
region="nativeElement">
</code-example>
This is actually a convenience method, implemented as `fixture.debugElement.nativeElement`.
<code-example
path="testing/src/app/banner/banner-initial.component.spec.ts"
region="debugElement-nativeElement">
</code-example>
There's a good reason for this circuitous path to the element.
The properties of the `nativeElement` depend upon the runtime environment.
You could be running these tests on a _non-browser_ platform that doesn't have a DOM or
whose DOM-emulation doesn't support the full `HTMLElement` API.
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.
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.
Here's the previous test, re-implemented with `fixture.debugElement.nativeElement`:
<code-example
path="testing/src/app/banner/banner-initial.component.spec.ts"
region="v4-test-4">
</code-example>
The `DebugElement` has other methods and properties that
are useful in tests, as you'll see elsewhere in this guide.
You import the `DebugElement` symbol from the Angular core library.
<code-example
path="testing/src/app/banner/banner-initial.component.spec.ts"
region="import-debug-element">
</code-example>
{@a by-css}
### _By.css()_
Although the tests in this guide all run in the browser,
some apps might run on a different platform at least some of the time.
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.
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.
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:
<code-example
path="testing/src/app/banner/banner-initial.component.spec.ts"
region="import-by">
</code-example>
The following example re-implements the previous test with
`DebugElement.query()` and the browser's `By.css` method.
<code-example
path="testing/src/app/banner/banner-initial.component.spec.ts"
region="v4-test-5">
</code-example>
Some noteworthy observations:
- The `By.css()` static method selects `DebugElement` nodes
with a [standard CSS selector](https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Getting_started/Selectors 'CSS selectors').
- The query returns a `DebugElement` for the paragraph.
- You must unwrap that result to get the paragraph element.
When you're filtering by CSS selector and only testing properties of a browser's _native element_, the `By.css` approach may be overkill.
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.

1826
aio/content/guide/testing-components-scenarios.md Normal file
View File

File diff suppressed because it is too large Load Diff

41
aio/content/guide/testing-pipes.md Normal file
View File

@ -0,0 +1,41 @@
# Testing Pipes
You can test [pipes](guide/pipes) without the Angular testing utilities.
<div class="alert is-helpful">
For the sample app that the testing guides describe, see the <live-example embedded-style noDownload>sample app</live-example>.
For the tests features in the testing guides, see <live-example stackblitz="specs" noDownload>tests</live-example>.
</div>
## Testing the `TitleCasePipe`
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 an implementation with a regular expression.
<code-example path="testing/src/app/shared/title-case.pipe.ts" header="app/shared/title-case.pipe.ts"></code-example>
Anything that uses a regular expression is worth testing thoroughly.
Use simple Jasmine to explore the expected cases and the edge cases.
<code-example path="testing/src/app/shared/title-case.pipe.spec.ts" region="excerpt" header="app/shared/title-case.pipe.spec.ts"></code-example>
{@a write-tests}
## Writing DOM tests to support a pipe test
These are tests of the pipe _in isolation_.
They can't tell if the `TitleCasePipe` is working properly as applied in the application components.
Consider adding component tests such as this one:
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="title-case-pipe" header="app/hero/hero-detail.component.spec.ts (pipe test)"></code-example>

199
aio/content/guide/testing-services.md Normal file
View File

@ -0,0 +1,199 @@
# Testing services
To check that your services are working as you intend, you can write tests specifically for them.
<div class="alert is-helpful">
For the sample app that the testing guides describe, see the <live-example embedded-style noDownload>sample app</live-example>.
For the tests features in the testing guides, see <live-example stackblitz="specs" noDownload>tests</live-example>.
</div>
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.
<code-example path="testing/src/app/demo/demo.spec.ts" region="ValueService" header="app/demo/demo.spec.ts"></code-example>
{@a services-with-dependencies}
## Services with dependencies
Services often depend on other services that Angular injects into the constructor.
In many cases, it's easy to create and _inject_ these dependencies by hand while
calling the service's constructor.
The `MasterService` is a simple example:
<code-example path="testing/src/app/demo/demo.ts" region="MasterService" header="app/demo/demo.ts"></code-example>
`MasterService` delegates its only method, `getValue`, to the injected `ValueService`.
Here are several ways to test it.
<code-example path="testing/src/app/demo/demo.spec.ts" region="MasterService" header="app/demo/demo.spec.ts"></code-example>
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.
Instead you can mock the dependency, use a dummy value, or create a
[spy](https://jasmine.github.io/2.0/introduction.html#section-Spies)
on the pertinent service method.
<div class="alert is-helpful">
Prefer spies as they are usually the easiest way to mock services.
</div>
These standard testing techniques are great for unit testing services in isolation.
However, you almost always inject services 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.
## Testing services with the _TestBed_
Your app relies on Angular [dependency injection (DI)](guide/dependency-injection)
to create services.
When a service has a dependent service, DI finds or creates that dependent service.
And if that dependent service has its own dependencies, DI finds-or-creates them as well.
As service _consumer_, you don't worry about any of this.
You don't worry about the order of constructor arguments or how they're created.
As a service _tester_, you must at least think about the first level of service dependencies
but you _can_ let Angular DI do the service creation and deal with constructor argument order
when you use the `TestBed` testing utility to provide and create services.
{@a testbed}
## Angular _TestBed_
The `TestBed` is the most important of the Angular testing utilities.
The `TestBed` creates a dynamically-constructed Angular _test_ module that emulates
an Angular [@NgModule](guide/ngmodules).
The `TestBed.configureTestingModule()` method takes a metadata object that can have most of the properties of an [@NgModule](guide/ngmodules).
To test a service, you set the `providers` metadata property with an
array of the services that you'll test or mock.
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="value-service-before-each" header="app/demo/demo.testbed.spec.ts (provide ValueService in beforeEach)"></code-example>
Then inject it inside a test by calling `TestBed.inject()` with the service class as the argument.
<div class="alert is-helpful">
**Note:** `TestBed.get()` was deprecated as of Angular version 9.
To help minimize breaking changes, Angular introduces a new function called `TestBed.inject()`, which you should use instead.
For information on the removal of `TestBed.get()`,
see its entry in the [Deprecations index](guide/deprecations#index).
</div>
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="value-service-inject-it"></code-example>
Or inside the `beforeEach()` if you prefer to inject the service as part of your setup.
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="value-service-inject-before-each"> </code-example>
When testing a service with a dependency, provide the mock in the `providers` array.
In the following example, the mock is a spy object.
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="master-service-before-each"></code-example>
The test consumes that spy in the same way it did earlier.
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="master-service-it">
</code-example>
{@a no-before-each}
## Testing without _beforeEach()_
Most test suites in this guide call `beforeEach()` to set the preconditions for each `it()` test
and rely on the `TestBed` to create classes and inject services.
There's another school of testing that never calls `beforeEach()` and prefers to create classes explicitly rather than use the `TestBed`.
Here's how you might rewrite one of the `MasterService` tests in that style.
Begin by putting re-usable, preparatory code in a _setup_ function instead of `beforeEach()`.
<code-example
path="testing/src/app/demo/demo.spec.ts"
region="no-before-each-setup"
header="app/demo/demo.spec.ts (setup)"></code-example>
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()`.
Then each test invokes `setup()` in its first line, before continuing
with steps that manipulate the test subject and assert expectations.
<code-example
path="testing/src/app/demo/demo.spec.ts"
region="no-before-each-test"></code-example>
Notice how the test uses
[_destructuring assignment_](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment)
to extract the setup variables that it needs.
<code-example
path="testing/src/app/demo/demo.spec.ts"
region="no-before-each-setup-call">
</code-example>
Many developers feel this approach is cleaner and more explicit than the
traditional `beforeEach()` style.
Although this testing guide follows the traditional style and
the default [CLI schematics](https://github.com/angular/angular-cli)
generate test files with `beforeEach()` and `TestBed`,
feel free to adopt _this alternative approach_ in your own projects.
## Testing HTTP services
Data services that make HTTP calls to remote servers typically inject and delegate
to the Angular [`HttpClient`](guide/http) service for XHR calls.
You can test a data service with an injected `HttpClient` spy as you would
test any service with a dependency.
<code-example
path="testing/src/app/model/hero.service.spec.ts"
region="test-with-spies"
header="app/model/hero.service.spec.ts (tests with spies)">
</code-example>
<div class="alert is-important">
The `HeroService` methods return `Observables`. You must
_subscribe_ to an observable to (a) cause it to execute and (b)
assert that the method succeeds or fails.
The `subscribe()` method takes a success (`next`) and fail (`error`) callback.
Make sure you provide _both_ callbacks so that you capture errors.
Neglecting to do so produces an asynchronous uncaught observable error that
the test runner will likely attribute to a completely different test.
</div>
## _HttpClientTestingModule_
Extended interactions between a data service and the `HttpClient` can be complex
and difficult to mock with spies.
The `HttpClientTestingModule` can make these testing scenarios more manageable.
While the _code sample_ accompanying this guide demonstrates `HttpClientTestingModule`,
this page defers to the [Http guide](guide/http#testing-http-requests),
which covers testing with the `HttpClientTestingModule` in detail.

794
aio/content/guide/testing-utility-apis.md Normal file
View File

@ -0,0 +1,794 @@
# Testing Utility APIs
This page describes the most useful Angular testing features.
The Angular testing utilities include the `TestBed`, the `ComponentFixture`, and a handful of functions that control the test environment.
The [_TestBed_](#testbed-api-summary) and [_ComponentFixture_](#component-fixture-api-summary) classes are covered separately.
Here's a summary of the stand-alone functions, in order of likely utility:
<table>
<tr>
<th>
Function
</th>
<th>
Description
</th>
</tr>
<tr>
<td style="vertical-align: top">
<code>async</code>
</td>
<td>
Runs the body of a test (`it`) or setup (`beforeEach`) function within a special _async test zone_.
See [discussion above](guide/testing-components-scenarios#async).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>fakeAsync</code>
</td>
<td>
Runs the body of a test (`it`) within a special _fakeAsync test zone_, enabling
a linear control flow coding style. See [discussion above](guide/testing-components-scenarios#fake-async).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>tick</code>
</td>
<td>
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_.
<div class="alert is-helpful">
The curious, dedicated reader might enjoy this lengthy blog post,
["_Tasks, microtasks, queues and schedules_"](https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/).
</div>
Accepts an optional argument that moves the virtual clock forward
by the specified number of milliseconds,
clearing asynchronous activities scheduled within that timeframe.
See [discussion above](guide/testing-components-scenarios#tick).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>inject</code>
</td>
<td>
Injects one or more services from the current `TestBed` injector into a test function.
It cannot inject a service provided by the component itself.
See discussion of the [debugElement.injector](guide/testing-components-scenarios#get-injected-services).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>discardPeriodicTasks</code>
</td>
<td>
When a `fakeAsync()` test ends with pending timer event _tasks_ (queued `setTimeOut` and `setInterval` callbacks),
the test fails with a clear error message.
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.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>flushMicrotasks</code>
</td>
<td>
When a `fakeAsync()` test ends with pending _micro-tasks_ such as unresolved promises,
the test fails with a clear error message.
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.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>ComponentFixtureAutoDetect</code>
</td>
<td>
A provider token for a service that turns on [automatic change detection](guide/testing-components-scenarios#automatic-change-detection).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>getTestBed</code>
</td>
<td>
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.
</td>
</tr>
</table>
<hr>
{@a testbed-class-summary}
## _TestBed_ class summary
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.
The module definition passed to `configureTestingModule`
is a subset of the `@NgModule` metadata properties.
<code-example language="javascript">
type TestModuleMetadata = {
providers?: any[];
declarations?: any[];
imports?: any[];
schemas?: Array&lt;SchemaMetadata | any[]&gt;;
};
</code-example>
{@a metadata-override-object}
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`.
<code-example language="javascript">
type MetadataOverride&lt;T&gt; = {
add?: Partial&lt;T&gt;;
remove?: Partial&lt;T&gt;;
set?: Partial&lt;T&gt;;
};
</code-example>
{@a testbed-methods}
{@a testbed-api-summary}
The `TestBed` API consists of static class methods that either update or reference a _global_ instance of the `TestBed`.
Internally, all static methods cover methods of the current runtime `TestBed` instance,
which is also returned by the `getTestBed()` function.
Call `TestBed` methods _within_ a `beforeEach()` to ensure a fresh start before each individual test.
Here are the most important static methods, in order of likely utility.
<table>
<tr>
<th>
Methods
</th>
<th>
Description
</th>
</tr>
<tr>
<td style="vertical-align: top">
<code>configureTestingModule</code>
</td>
<td>
The testing shims (`karma-test-shim`, `browser-test-shim`)
establish the [initial test environment](guide/testing) and a default testing module.
The default testing module is configured with basic declaratives and some Angular service substitutes that every tester needs.
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.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>compileComponents</code>
</td>
<td>
Compile the testing module asynchronously after you've finished configuring it.
You **must** call this method if _any_ of the testing module components have a `templateUrl`
or `styleUrls` because fetching component template and style files is necessarily asynchronous.
See [above](guide/testing-components-scenarios#compile-components).
After calling `compileComponents`, the `TestBed` configuration is frozen for the duration of the current spec.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>createComponent<T></code>
</td>
<td>
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.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>overrideModule</code>
</td>
<td>
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.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>overrideComponent</code>
</td>
<td>
Replace metadata for the given component class, which could be nested deeply
within an inner module.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>overrideDirective</code>
</td>
<td>
Replace metadata for the given directive class, which could be nested deeply
within an inner module.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>overridePipe</code>
</td>
<td>
Replace metadata for the given pipe class, which could be nested deeply
within an inner module.
</td>
</tr>
<tr>
<td style="vertical-align: top">
{@a testbed-inject}
<code>inject</code>
</td>
<td>
Retrieve a service from the current `TestBed` injector.
The `inject` function is often adequate for this purpose.
But `inject` throws an error if it can't provide the service.
What if the service is optional?
The `TestBed.inject()` method takes an optional second parameter,
the object to return if Angular can't find the provider
(`null` in this example):
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="testbed-get-w-null" header="app/demo/demo.testbed.spec.ts"></code-example>
After calling `TestBed.inject`, the `TestBed` configuration is frozen for the duration of the current spec.
</td>
</tr>
<tr>
<td style="vertical-align: top">
{@a testbed-initTestEnvironment}
<code>initTestEnvironment</code>
</td>
<td>
Initialize the testing environment for the entire test run.
The testing shims (`karma-test-shim`, `browser-test-shim`) call it for you
so there is rarely a reason for you to call it yourself.
You may call this method _exactly once_. If you must change
this default in the middle of your test run, call `resetTestEnvironment` first.
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>`.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>resetTestEnvironment</code>
</td>
<td>
Reset the initial test environment, including the default testing module.
</td>
</tr>
</table>
A few of the `TestBed` instance methods are not covered by static `TestBed` _class_ methods.
These are rarely needed.
{@a component-fixture-api-summary}
## The _ComponentFixture_
The `TestBed.createComponent<T>`
creates an instance of the component `T`
and returns a strongly typed `ComponentFixture` for that component.
The `ComponentFixture` properties and methods provide access to the component,
its DOM representation, and aspects of its Angular environment.
{@a component-fixture-properties}
### _ComponentFixture_ properties
Here are the most important properties for testers, in order of likely utility.
<table>
<tr>
<th>
Properties
</th>
<th>
Description
</th>
</tr>
<tr>
<td style="vertical-align: top">
<code>componentInstance</code>
</td>
<td>
The instance of the component class created by `TestBed.createComponent`.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>debugElement</code>
</td>
<td>
The `DebugElement` associated with the root element of the component.
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](#debug-element-details).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>nativeElement</code>
</td>
<td>
The native DOM element at the root of the component.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>changeDetectorRef</code>
</td>
<td>
The `ChangeDetectorRef` for 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.
</td>
</tr>
</table>
{@a component-fixture-methods}
### _ComponentFixture_ methods
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.
<table>
<tr>
<th>
Methods
</th>
<th>
Description
</th>
</tr>
<tr>
<td style="vertical-align: top">
<code>detectChanges</code>
</td>
<td>
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`.
Runs `checkNoChanges` afterwards to confirm that there are no circular updates unless
called as `detectChanges(false)`;
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>autoDetectChanges</code>
</td>
<td>
Set this to `true` when you want the fixture to detect changes automatically.
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.
The default is `false`. Testers who prefer fine control over test behavior
tend to keep it `false`.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>checkNoChanges</code>
</td>
<td>
Do a change detection run to make sure there are no pending changes.
Throws an exceptions if there are.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>isStable</code>
</td>
<td>
If the fixture is currently _stable_, returns `true`.
If there are async tasks that have not completed, returns `false`.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>whenStable</code>
</td>
<td>
Returns a promise that resolves when the fixture is stable.
To resume testing after completion of asynchronous activity or
asynchronous change detection, hook that promise.
See [above](guide/testing-components-scenarios#when-stable).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>destroy</code>
</td>
<td>
Trigger component destruction.
</td>
</tr>
</table>
{@a debug-element-details}
#### _DebugElement_
The `DebugElement` provides crucial insights into the component's DOM representation.
From the test root component's `DebugElement` returned by `fixture.debugElement`,
you can walk (and query) the fixture's entire element and component subtrees.
Here are the most useful `DebugElement` members for testers, in approximate order of utility:
<table>
<tr>
<th>
Member
</th>
<th>
Description
</th>
</tr>
<tr>
<td style="vertical-align: top">
<code>nativeElement</code>
</td>
<td>
The corresponding DOM element in the browser (null for WebWorkers).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>query</code>
</td>
<td>
Calling `query(predicate: Predicate<DebugElement>)` returns the first `DebugElement`
that matches the [predicate](#query-predicate) at any depth in the subtree.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>queryAll</code>
</td>
<td>
Calling `queryAll(predicate: Predicate<DebugElement>)` returns all `DebugElements`
that matches the [predicate](#query-predicate) at any depth in subtree.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>injector</code>
</td>
<td>
The host dependency injector.
For example, the root element's component instance injector.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>componentInstance</code>
</td>
<td>
The element's own component instance, if it has one.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>context</code>
</td>
<td>
An object that provides parent context for this element.
Often an ancestor component instance that governs this element.
When an element is repeated within `*ngFor`, the context is an `NgForRow` whose `$implicit`
property is the value of the row instance value.
For example, the `hero` in `*ngFor="let hero of heroes"`.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>children</code>
</td>
<td>
The immediate `DebugElement` children. Walk the tree by descending through `children`.
<div class="alert is-helpful">
`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.
</div>
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>parent</code>
</td>
<td>
The `DebugElement` parent. Null if this is the root element.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>name</code>
</td>
<td>
The element tag name, if it is an element.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>triggerEventHandler</code>
</td>
<td>
Triggers the event by its name if there is a corresponding listener
in the element's `listeners` collection.
The second parameter is the _event object_ expected by the handler.
See [above](guide/testing-components-scenarios#trigger-event-handler).
If the event lacks a listener or there's some other problem,
consider calling `nativeElement.dispatchEvent(eventObject)`.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>listeners</code>
</td>
<td>
The callbacks attached to the component's `@Output` properties and/or the element's event properties.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>providerTokens</code>
</td>
<td>
This component's injector lookup tokens.
Includes the component itself plus the tokens that the component lists in its `providers` metadata.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>source</code>
</td>
<td>
Where to find this element in the source component template.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>references</code>
</td>
<td>
Dictionary of objects associated with template local variables (e.g. `#foo`),
keyed by the local variable name.
</td>
</tr>
</table>
{@a query-predicate}
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":
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="custom-predicate" header="app/demo/demo.testbed.spec.ts"></code-example>
The Angular `By` class has three static methods for common predicates:
- `By.all` - return all elements.
- `By.css(selector)` - return elements with matching CSS selectors.
- `By.directive(directive)` - return elements that Angular matched to an instance of the directive class.
<code-example path="testing/src/app/hero/hero-list.component.spec.ts" region="by" header="app/hero/hero-list.component.spec.ts"></code-example>
<hr>

3483
aio/content/guide/testing.md
View File

File diff suppressed because it is too large Load Diff

2
aio/content/guide/upgrade-setup.md
View File

@ -308,7 +308,7 @@ So when IE is refreshed (manually or automatically by `ng serve`), sometimes the
## Appendix: Test using `fakeAsync()/async()`
If you use the `fakeAsync()/async()` helper function to run unit tests (for details, read the [Testing guide](guide/testing#async-test-with-fakeasync)), you need to import `zone.js/dist/zone-testing` in your test setup file.
If you use the `fakeAsync()/async()` helper function to run unit tests (for details, read the [Testing guide](guide/testing-components-scenarios#fake-async)), you need to import `zone.js/dist/zone-testing` in your test setup file.
<div class="alert is-important">
If you create project with `Angular/CLI`, it is already imported in `src/test.ts`.

70
aio/content/navigation.json
View File

@ -526,28 +526,74 @@
"url": "guide/angular-compiler-options",
"title": "Angular Compiler Options",
"tooltip": "Configuring AOT compilation."
},
{
},
{
"url": "guide/aot-metadata-errors",
"title": "AOT Metadata Errors",
"tooltip": "Troubleshooting AOT compilation."
},
{
"url": "guide/template-typecheck",
"title": "Template Type-checking",
"tooltip": "Template type-checking in Angular."
}
]
},
},
{
"url": "guide/template-typecheck",
"title": "Template Type-checking",
"tooltip": "Template type-checking in Angular."
}
]
},
{
"url": "guide/build",
"title": "Building & Serving",
"tooltip": "Building and serving Angular apps."
},
{
"url": "guide/testing",
"title": "Testing",
"tooltip": "Techniques and practices for testing an Angular app."
"tooltip": "Testing your Angular apps.",
"children": [
{
"url": "guide/testing",
"title": "Intro to Testing",
"tooltip": "Introduction to testing an Angular app."
},
{
"url": "guide/testing-code-coverage",
"title": "Code Coverage",
"tooltip": "Determine how much of your code is tested."
},
{
"url": "guide/testing-services",
"title": "Testing Services",
"tooltip": "How to test services."
},
{
"url": "guide/testing-components-basics",
"title": "Basics of Testing Components",
"tooltip": "The fundamentals of how to test components."
},
{
"url": "guide/testing-components-scenarios",
"title": "Component Testing Scenarios",
"tooltip": "Use cases for testing components."
},
{
"url": "guide/testing-attribute-directives",
"title": "Testing Attribute Directives",
"tooltip": "How to test attribute directives."
},
{
"url": "guide/testing-pipes",
"title": "Testing Pipes",
"tooltip": "Writing tests for pipes."
},
{
"url": "guide/test-debugging",
"title": "Debugging Tests",
"tooltip": "How to debug tests."
},
{
"url": "guide/testing-utility-apis",
"title": "Testing Utility APIs",
"tooltip": "Features of the Angular testing utilities."
}
]
},
{
"url": "guide/deployment",