+
+The `TestBed.compileComponents()` method (see [below](#compile-components)) calls `XHR`
+to read external template and css files during "just-in-time" compilation.
+Write tests that call `compileComponents()` with the `async()` utility.
+
+
+
+Here's the previous `fakeAsync()` test, re-written with the `async()` utility.
+
+
+
+The [discussion below](#routing-component) covers testing components that require the router.
+
+
+
+The immediate goal is to test the `DashboardHeroComponent`, not the `DashboardComponent`,
+so, try the second and third options.
+
+{@a dashboard-standalone}
+
+#### Test _DashboardHeroComponent_ stand-alone
+
+Here's the meat of the spec file setup.
+
+
+
+This small test demonstrates how Angular tests can verify a component's visual
+representation—something not possible with
+[component class tests](guide/testing-components-basics#component-class-testing)—at
+low cost and without resorting to much slower and more complicated end-to-end tests.
+
+
+
+#### Clicking
+
+Clicking the hero should raise a `selected` event that
+the host component (`DashboardComponent` presumably) can hear:
+
+`.
+
+It has Angular properties and methods that abstract interaction with the native element.
+This test calls the `DebugElement.triggerEventHandler` with the "click" event name.
+The "click" event binding responds by calling `DashboardHeroComponent.click()`.
+
+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.
+
+The test triggered a "click" event with a `null` event object.
+
+
+
+
+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 (if any) was pressed during the click.
+The `RouterLink` directive throws an error if the event object is missing.
+
+
+
+#### Click the element
+
+The following test alternative calls the native element's own `click()` method,
+which is perfectly fine for _this component_.
+
+
+
+
+{@a click-helper}
+
+#### _click()_ helper
+
+Clicking a button, an anchor, or an arbitrary HTML element is a common test task.
+
+Make that consistent and easy by encapsulating the _click-triggering_ process
+in a helper such as the `click()` function below:
+
+
+
+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.
+
+
+
+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.
+
+
+
+Here's the previous test, rewritten using the click helper.
+
+
+
+
+
+
+{@a component-inside-test-host}
+
+## Component inside a test host
+
+The previous tests played the role of the host `DashboardComponent` themselves.
+But does the `DashboardHeroComponent` work correctly when properly data-bound to a host component?
+
+You could test with the actual `DashboardComponent`.
+But doing so could require a lot of setup,
+especially when its template features an `*ngFor` repeater,
+other components, layout HTML, additional bindings,
+a constructor that injects multiple services,
+and it starts interacting with those services right away.
+
+Imagine the effort to disable these distractions, just to prove a point
+that can be made satisfactorily with a _test host_ like this one:
+
+
+
+This test host binds to `DashboardHeroComponent` as the `DashboardComponent` would
+but without the noise of the `Router`, the `HeroService`, or 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 will be able to easily check `selectedHero` to verify that the
+`DashboardHeroComponent.selected` event emitted the expected hero.
+
+The setup for the _test-host_ tests is similar to the setup for the stand-alone tests:
+
+
+
+This testing module configuration shows three important differences:
+
+1. It _declares_ both the `DashboardHeroComponent` and the `TestHostComponent`.
+1. It _creates_ the `TestHostComponent` instead of the `DashboardHeroComponent`.
+1. The `TestHostComponent` sets the `DashboardHeroComponent.hero` with a binding.
+
+The `createComponent` returns a `fixture` that holds an instance of `TestHostComponent` instead of an instance of `DashboardHeroComponent`.
+
+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:
+
+
+
+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.
+
+
+
+{@a routing-component}
+
+## Routing component
+
+A _routing component_ is a component that tells the `Router` to navigate to another component.
+The `DashboardComponent` is a _routing component_ because the user can
+navigate to the `HeroDetailComponent` by clicking on one of the _hero buttons_ on the dashboard.
+
+Routing is pretty complicated.
+Testing the `DashboardComponent` seemed daunting in part because it involves the `Router`,
+which it injects together with the `HeroService`.
+
+
+
+Mocking the `HeroService` with a spy is a [familiar story](#component-with-async-service).
+But the `Router` has a complicated API and is entwined with other services and application preconditions. Might it be difficult to mock?
+
+Fortunately, not in this case because the `DashboardComponent` isn't doing much with the `Router`
+
+
+
+
+This is often the case with _routing components_.
+As a rule you test the component, not the router,
+and care only if the component navigates with the right address under the given conditions.
+
+Providing a router spy for _this component_ test suite happens to be as easy
+as providing a `HeroService` spy.
+
+
+
+The following test clicks the displayed hero and confirms that
+`Router.navigateByUrl` is called with the expected url.
+
+
+
+{@a routed-component-w-param}
+
+## Routed components
+
+A _routed component_ is the destination of a `Router` navigation.
+It can be trickier to test, especially when the route to the component _includes parameters_.
+The `HeroDetailComponent` is a _routed component_ that is the destination of such a route.
+
+When a user clicks a _Dashboard_ hero, the `DashboardComponent` tells the `Router`
+to navigate to `heroes/:id`.
+The `:id` is a route parameter whose value is the `id` of the hero to edit.
+
+The `Router` matches that URL to a route to the `HeroDetailComponent`.
+It creates an `ActivatedRoute` object with the routing information and
+injects it into a new instance of the `HeroDetailComponent`.
+
+Here's the `HeroDetailComponent` constructor:
+
+
+
+The `HeroDetail` component needs the `id` parameter so it can fetch
+the corresponding hero via the `HeroDetailService`.
+The component has to get the `id` from the `ActivatedRoute.paramMap` property
+which is an `Observable`.
+
+It can't just reference the `id` property of the `ActivatedRoute.paramMap`.
+The component has to _subscribe_ to the `ActivatedRoute.paramMap` observable and be prepared
+for the `id` to change during its lifetime.
+
+
+
+
+
+The [ActivatedRoute in action](guide/router#activated-route-in-action) section of the [Router](guide/router) guide covers `ActivatedRoute.paramMap` in more detail.
+
+
+
+Tests can explore how the `HeroDetailComponent` responds to different `id` parameter values
+by manipulating the `ActivatedRoute` injected into the component's constructor.
+
+You know how to spy on the `Router` and a data service.
+
+You'll take a different approach with `ActivatedRoute` because
+
+- `paramMap` returns an `Observable` that can emit more than one value
+ during a test.
+- You need the router helper function, `convertToParamMap()`, to create a `ParamMap`.
+- Other _routed component_ tests need a test double for `ActivatedRoute`.
+
+These differences argue for a re-usable stub class.
+
+#### _ActivatedRouteStub_
+
+The following `ActivatedRouteStub` class serves as a test double for `ActivatedRoute`.
+
+
+
+Consider placing such helpers in a `testing` folder sibling to the `app` folder.
+This sample puts `ActivatedRouteStub` in `testing/activated-route-stub.ts`.
+
+
+
+Consider writing a more capable version of this stub class with
+the [_marble testing library_](#marble-testing).
+
+
+
+{@a tests-w-test-double}
+
+#### Testing with _ActivatedRouteStub_
+
+Here's a test demonstrating the component's behavior when the observed `id` refers to an existing hero:
+
+
+
+
+
+The `createComponent()` method and `page` object are discussed [below](#page-object).
+Rely on your intuition for now.
+
+
+
+When the `id` cannot be found, the component should re-route to the `HeroListComponent`.
+
+The test suite setup provided the same router spy [described above](#routing-component) which spies on the router without actually navigating.
+
+This test expects the component to try to navigate to the `HeroListComponent`.
+
+
+
+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:
+
+
+
+
+
+## Nested component tests
+
+Component templates often have nested components, whose templates
+may contain more components.
+
+The component tree can be very deep and, most of the time, the nested components
+play no role in testing the component at the top of the tree.
+
+The `AppComponent`, for example, displays a navigation bar with anchors and their `RouterLink` directives.
+
+
+
+While the `AppComponent` _class_ is empty,
+you may want to write unit tests to confirm that the links are wired properly
+to the `RouterLink` directives, perhaps for the reasons [explained below](#why-stubbed-routerlink-tests).
+
+To validate the links, you don't need the `Router` to navigate and you don't
+need the `
` to mark where the `Router` inserts _routed components_.
+
+The `BannerComponent` and `WelcomeComponent`
+(indicated by `` and ``) are also irrelevant.
+
+Yet any test that creates the `AppComponent` in the DOM will also create instances of
+these three components and, if you let that happen,
+you'll have to configure the `TestBed` to create them.
+
+If you neglect to declare them, the Angular compiler won't recognize the
+``, ``, and `` tags in the `AppComponent` template
+and will throw an error.
+
+If you declare the real components, you'll also have to declare _their_ nested components
+and provide for _all_ services injected in _any_ component in the tree.
+
+That's too much effort just to answer a few simple questions about links.
+
+This section describes two techniques for minimizing the setup.
+Use them, alone or in combination, to stay focused on the testing the primary component.
+
+{@a stub-component}
+
+##### Stubbing unneeded components
+
+In the first technique, you create and declare stub versions of the components
+and directive that play little or no role in the tests.
+
+` element and the `routerLink` attribute
+because you declared a corresponding `AppComponent` and `RouterLinkDirectiveStub`
+in the `TestBed` configuration.
+
+But the compiler won't throw an error when it encounters ``, ``, or ``.
+It simply renders them as empty tags and the browser ignores them.
+
+You no longer need the stub components.
+
+#### Use both techniques together
+
+These are techniques for _Shallow Component Testing_ ,
+so-named because they reduce the visual surface of the component to just those elements
+in the component's template that matter for tests.
+
+The `NO_ERRORS_SCHEMA` approach is the easier of the two but don't overuse it.
+
+The `NO_ERRORS_SCHEMA` also prevents the compiler from telling you about the missing
+components and attributes that you omitted inadvertently or misspelled.
+You could waste hours chasing phantom bugs that the compiler would have caught in an instant.
+
+The _stub component_ approach has another advantage.
+While the stubs in _this_ example were empty,
+you could give them stripped-down templates and classes if your tests
+need to interact with them in some way.
+
+In practice you will combine the two techniques in the same setup,
+as seen in this example.
+
+` element
+and applies the `RouterLinkStubDirective` to the anchors with the `routerLink` attribute,
+but it ignores the `` and `` tags.
+
+` anchor elements in `AppComponent`) to the stub directive's `onClick` method.
+
+Clicking the anchor should trigger the `onClick()` method,
+which sets the stub's telltale `navigatedTo` property.
+Tests inspect `navigatedTo` to confirm that clicking the anchor
+set the expected route definition.
+
+
+
+Whether the router is configured properly to navigate with that route definition is a
+question for a separate set of tests.
+
+
+
+{@a by-directive}
+{@a inject-directive}
+
+#### _By.directive_ and injected directives
+
+A little more setup triggers the initial data binding and gets references to the navigation links:
+
+
+
+The "click" test _in this example_ is misleading.
+It tests the `RouterLinkDirectiveStub` 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.
+
+
+
+{@a why-stubbed-routerlink-tests}
+
+#### What good are these tests?
+
+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.
+
+
+
+A future guide update will explain how to write such
+tests with the `RouterTestingModule`.
+
+
+
+
+
+
+
+You can ignore this section if you _only_ run tests with the CLI `ng test` command
+because the CLI compiles the application before running the tests.
+
+
+
+If you run tests in a **non-CLI environment**, the tests may fail with a message like this one:
+
+
+Error: This test module uses the component BannerComponent
+which is using a "templateUrl" or "styleUrls", but they were never compiled.
+Please call "TestBed.compileComponents" before your test.
+
+
+The root of the problem is at least one of the components involved in the test
+specifies an external template or CSS file as
+the following version of the `BannerComponent` does.
+
+
+
+If you neglect to make the test function async
+(e.g., forget to use `async()` as described below),
+you'll see this error message
+
+
+Error: ViewDestroyedError: Attempt to use a destroyed view
+
+
+
+
+A typical approach is to divide the setup logic into two separate `beforeEach()` functions:
+
+1. An async `beforeEach()` that compiles the components
+1. A synchronous `beforeEach()` that performs the remaining setup.
+
+To follow this pattern, import the `async()` helper with the other testing symbols.
+
+
+
+
+#### The async _beforeEach_
+
+Write the first async `beforeEach` like this.
+
+
+
+Do not re-configure the `TestBed` after calling `compileComponents()`.
+
+
+
+Calling `compileComponents()` closes the current `TestBed` instance to further configuration.
+You cannot call any more `TestBed` configuration methods, not `configureTestingModule()`
+nor any of the `override...` methods. The `TestBed` throws an error if you try.
+
+Make `compileComponents()` the last step
+before calling `TestBed.createComponent()`.
+
+#### The synchronous _beforeEach_
+
+The second, synchronous `beforeEach()` contains the remaining setup steps,
+which include creating the component and querying for elements to inspect.
+
+
+
+
+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:
+
+- `NgModel` and friends in the `FormsModule` to enable two-way data binding.
+- The `TitleCasePipe` from the `shared` folder.
+- Router services (which these tests are stubbing).
+- Hero data access services (also stubbed).
+
+One approach is to configure the testing module from the individual pieces as in this example:
+
+
+
+Notice that the `beforeEach()` is asynchronous and calls `TestBed.compileComponents`
+because the `HeroDetailComponent` has an external template and css file.
+
+As explained in [_Calling compileComponents()_](#compile-components) above,
+these tests could be run in a non-CLI environment
+where Angular would have to compile them in the browser.
+
+
+
+#### Import a shared module
+
+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:
+
+
+
+Importing the component's feature module can be the easiest way to configure tests
+when there are many mutual dependencies within the module and
+the module is small, as feature modules tend to be.
+
+
+
+
+
+These tests could fail or timeout if the `HeroDetailService` made its own XHR calls to a remote server.
+There might not be a remote server to call.
+
+Fortunately, the `HeroDetailService` delegates responsibility for remote data access to an injected `HeroService`.
+
+
+
+What if you aren't so lucky. What if faking the `HeroService` is hard?
+What if `HeroDetailService` makes its own server requests?
+
+The `TestBed.overrideComponent` method can replace the component's `providers` with easy-to-manage _test doubles_
+as seen in the following setup variation:
+
+
+ type MetadataOverride<T> = {
+ add?: Partial<T>;
+ remove?: Partial<T>;
+ set?: Partial<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.
+
+The type parameter, `T`, is the kind of metadata you'd pass to the `@Component` decorator:
+
+
+ selector?: string;
+ template?: string;
+ templateUrl?: string;
+ providers?: any[];
+ ...
+
+
+{@a spy-stub}
+
+#### Provide a _spy stub_ (_HeroDetailServiceSpy_)
+
+This example completely replaces the component's `providers` array with a new array containing a `HeroDetailServiceSpy`.
+
+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:
+
+
+
+ For the sample app that the testing guides describe, see the sample app .
+
+ For the tests features in the testing guides, see tests .
+
+
+
+## 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.
+
+
+
+ For the sample app that the testing guides describe, see the sample app .
+
+ For the tests features in the testing guides, see tests .
+
+
+
+
+Services are often the easiest files to unit test.
+Here are some synchronous and asynchronous unit tests of the `ValueService`
+written without assistance from Angular testing utilities.
+
+
+
+Prefer spies as they are usually the easiest way to mock services.
+
+
+
+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.
+
+
+
+**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).
+
+
+
+
+
+When testing a service with a dependency, provide the mock in the `providers` array.
+
+In the following example, the mock is a spy object.
+
+
+
+
+{@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()`.
+
+
+
+
+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.
+
+
+
+
+
+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.
+
+
+
+## _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.
+
diff --git a/aio/content/guide/testing-utility-apis.md b/aio/content/guide/testing-utility-apis.md
new file mode 100644
index 0000000000..8152d75acf
--- /dev/null
+++ b/aio/content/guide/testing-utility-apis.md
@@ -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:
+
+
+
+
+ Function
+
+
+ Description
+
+
+
+
+
+ async
+
+
+
+
+ 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).
+
+
+
+
+
+
+ fakeAsync
+
+
+
+
+ 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).
+
+
+
+
+
+
+ tick
+
+
+
+
+ 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_.
+
+
+
+ The curious, dedicated reader might enjoy this lengthy blog post,
+ ["_Tasks, microtasks, queues and schedules_"](https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/).
+
+
+
+ Accepts an optional argument that moves the virtual clock forward
+ by the specified number of milliseconds,
+ clearing asynchronous activities scheduled within that timeframe.
+ See [discussion above](guide/testing-components-scenarios#tick).
+
+
+
+
+
+
+ inject
+
+
+
+
+ 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).
+
+
+
+
+
+
+ discardPeriodicTasks
+
+
+
+
+ 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.
+
+
+
+
+
+
+ flushMicrotasks
+
+
+
+
+ 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.
+
+
+
+
+
+
+ ComponentFixtureAutoDetect
+
+
+
+
+ A provider token for a service that turns on [automatic change detection](guide/testing-components-scenarios#automatic-change-detection).
+
+
+
+
+
+
+ getTestBed
+
+
+
+
+ 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.
+
+
+
+
+
+
+ type TestModuleMetadata = {
+ providers?: any[];
+ declarations?: any[];
+ imports?: any[];
+ schemas?: Array<SchemaMetadata | any[]>;
+ };
+
+
+{@a metadata-override-object}
+
+Each override method takes a `MetadataOverride` where `T` is the kind of metadata
+appropriate to the method, that is, the parameter of an `@NgModule`,
+`@Component`, `@Directive`, or `@Pipe`.
+
+
+ type MetadataOverride<T> = {
+ add?: Partial<T>;
+ remove?: Partial<T>;
+ set?: Partial<T>;
+ };
+
+
+{@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.
+
+
+
+
+ Methods
+
+
+ Description
+
+
+
+
+
+ configureTestingModule
+
+
+
+
+ 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.
+
+
+
+
+
+
+ compileComponents
+
+
+
+
+ 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.
+
+
+
+
+
+
+ createComponent
+
+
+
+
+ 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.
+
+
+
+
+
+
+ overrideModule
+
+
+
+ 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.
+
+
+
+
+
+
+ {@a testbed-inject}
+ inject
+
+
+
+
+ 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):
+
+
+
+
+
+
+ {@a testbed-initTestEnvironment}
+ initTestEnvironment
+
+
+
+ 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-/testing/`.
+
+
+
+
+
+
+ resetTestEnvironment
+
+
+
+ Reset the initial test environment, including the default testing module.
+
+
+
+
+
+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`
+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.
+
+
+
+
+ Properties
+
+
+ Description
+
+
+
+
+
+ componentInstance
+
+
+
+
+ The instance of the component class created by `TestBed.createComponent`.
+
+
+
+
+
+
+ debugElement
+
+
+
+
+ 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).
+
+
+
+
+
+
+ nativeElement
+
+
+
+
+ The native DOM element at the root of the component.
+
+
+
+
+
+
+ changeDetectorRef
+
+
+
+
+ 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.
+
+
+
+
+
+{@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.
+
+
+
+
+ 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`.
+
+ Runs `checkNoChanges` afterwards to confirm that there are no circular updates unless
+ called as `detectChanges(false)`;
+
+
+
+
+
+
+ autoDetectChanges
+
+
+
+
+ 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`.
+
+
+
+
+
+
+ checkNoChanges
+
+
+
+
+ Do a change detection run to make sure there are no pending changes.
+ Throws an exceptions if there are.
+
+
+
+
+
+ isStable
+
+
+
+
+ If the fixture is currently _stable_, returns `true`.
+ If there are async tasks that have not completed, returns `false`.
+
+
+
+
+
+
+ whenStable
+
+
+
+
+ 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).
+
+
+
+
+
+
+ destroy
+
+
+
+
+ Trigger component destruction.
+
+
+
+
+
+{@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:
+
+
+
+
+ Member
+
+
+ Description
+
+
+
+
+
+ nativeElement
+
+
+
+
+ The corresponding DOM element in the browser (null for WebWorkers).
+
+
+
+
+
+
+ query
+
+
+
+
+ Calling `query(predicate: Predicate)` returns the first `DebugElement`
+ that matches the [predicate](#query-predicate) at any depth in the subtree.
+
+
+
+
+
+
+ queryAll
+
+
+
+
+ Calling `queryAll(predicate: Predicate)` returns all `DebugElements`
+ that matches the [predicate](#query-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.
+
+ 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
+
+
+
+
+ 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
+
+
+
+ The `DebugElement` parent. Null if this is the root element.
+
+
+
+
+
+
+ name
+
+
+
+
+ The element tag name, if it is an element.
+
+
+
+
+
+
+ triggerEventHandler
+
+
+
+ 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)`.
+
+
+
+
+
+
+ listeners
+
+
+
+
+ The callbacks attached to the component's `@Output` properties and/or the element's event properties.
+
+
+
+
+
+
+ providerTokens
+
+
+
+
+ This component's injector lookup tokens.
+ Includes the component itself plus the tokens that the component lists in its `providers` metadata.
+
+
+
+
+
+
+ source
+
+
+
+
+ Where to find this element in the source component template.
+
+
+
+
+
+
+ references
+
+
+
+
+ Dictionary of objects associated with template local variables (e.g. `#foo`),
+ keyed by the local variable name.
+
+
+
+
+
+{@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":
+
+Sample app
-- Tests
+Before writing tests for your Angular app, you should have a basic understanding of the following concepts:
+
+* Angular fundamentals
+* JavaScript
+* HTML
+* CSS
+* [Angular CLI](/cli)
+
+ For the sample app that the testing guides describe, see the sample app .
+
+ For the tests features in the testing guides, see tests .
+
+
+
+{@a setup}
+
+## Set up testing
The Angular CLI downloads and installs everything you need to test an Angular application with the [Jasmine test framework](https://jasmine.github.io/).
@@ -39,7 +57,7 @@ Chrome ...: Executed 3 of 3 SUCCESS (0.135 secs / 0.205 secs)
The last line of the log is the most important.
It shows that Karma ran three tests that all passed.
-A chrome browser also opens and displays the test output in the "Jasmine HTML Reporter" like this.
+A Chrome browser also opens and displays the test output in the "Jasmine HTML Reporter" like this.
@@ -53,7 +71,7 @@ Meanwhile, the `ng test` command is watching for changes.
To see this in action, make a small change to `app.component.ts` and save.
The tests run again, the browser refreshes, and the new test results appear.
-#### Configuration
+## Configuration
The CLI takes care of Jasmine and Karma configuration for you.
@@ -65,14 +83,14 @@ The CLI constructs the full runtime configuration in memory, based on applicatio
Search the web for more details about Jasmine and Karma configuration.
-#### Other test frameworks
+### Other test frameworks
You can also unit test an Angular app with other testing libraries and test runners.
Each library and runner has its own distinctive installation procedures, configuration, and syntax.
Search the web to learn more.
-#### Test file name and location
+### Test file name and location
Look inside the `src/app` folder.
@@ -89,6 +107,34 @@ The root file names (`app.component`) are the same for both files.
Adopt these two conventions in your own projects for _every kind_ of test file.
+{@a q-spec-file-location}
+
+#### Place your spec file next to the file it tests
+
+It's a good idea to put unit test spec files in the same folder
+as the application source code files that they test:
+
+- Such tests are easy to find.
+- You see at a glance if a part of your application lacks tests.
+- Nearby tests can reveal how a part works in context.
+- When you move the source (inevitable), you remember to move the test.
+- When you rename the source file (inevitable), you remember to rename the test file.
+
+{@a q-specs-in-test-folder}
+
+#### Place your spec files in a test folder
+
+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.
+
+It's often better to create an appropriate folder for them in the `tests` directory.
+
+Of course specs that test the test helpers belong in the `test` folder,
+next to their corresponding helper files.
+
+
{@a ci}
## Set up continuous integration
@@ -228,3415 +274,20 @@ Now you can run the following commands to use the `--no-sandbox` flag:
-{@a code-coverage}
-## Enable code coverage reports
+
- ng test --no-watch --code-coverage
-
+* [Code coverage](guide/testing-code-coverage)—find out how much of your app your tests are covering and how to specify required amounts.
+* [Testing services](guide/testing-services)—learn how to test the services your app uses.
+* [Basics of testing components](guide/testing-components-basics)—discover the basics of testing Angular components.
+* [Component testing scenarios](guide/testing-components-scenarios)—read about the various kinds of component testing scenarios and use cases.
+* [Testing attribute directives](guide/testing-attribute-directives)—learn about how to test your attribute directives.
+* [Testing pipes](guide/testing-pipes)—find out how to test attribute directives.
+* [Debugging tests](guide/testing-attribute-directives)—uncover common testing bugs.
+* [Testing utility APIs](guide/testing-utility-apis)—get familiar with Angular testing features.
-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.
-
-## Service Tests
-
-Services are often the easiest files to unit test.
-Here are some synchronous and asynchronous unit tests of the `ValueService`
-written without assistance from Angular testing utilities.
-
-
-
-Prefer spies as they are usually the easiest way to mock services.
-
-
-
-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.
-
-
-
-
-Then inject it inside a test by calling `TestBed.inject()` with the service class as the argument.
-
-
-
-**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).
-
-
-
-
-
-
-Or inside the `beforeEach()` if you prefer to inject the service as part of your setup.
-
-
-
-
-When testing a service with a dependency, provide the mock in the `providers` array.
-
-In the following example, the mock is a spy object.
-
-
-
-
-{@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()`.
-
-
-
-
-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.
-
-
-
-
-
-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.
-
-
-
-#### _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.
-
-
-## Component Test Basics
-
-A component, unlike all other parts of an Angular application,
-combines an HTML template and a TypeScript class.
-The component truly is the template and the class _working together_. 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.
-
-### Component class testing
-
-Test a component class on its own as you would test a service class.
-
-Consider this `LightswitchComponent` which toggles a light on and off
-(represented by an on-screen message) when the user clicks the button.
-
-
-ng generate component banner --inline-template --inline-style --module app
-
-
-It also generates an initial test file for the component, `banner-external.component.spec.ts`, that looks like this:
-
-
-
-Because `compileComponents` is asynchronous, it uses
-the [`async`](api/core/testing/async) utility
-function imported from `@angular/core/testing`.
-
-Please refer to the [async](#async) section for more details.
-
-
-
-#### 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:
-
-
-
-
-
-
-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.
-
-
-
-{@a create-component}
-
-#### _createComponent()_
-
-After configuring `TestBed`, you call its `createComponent()` method.
-
-
-
-
-`TestBed.createComponent()` creates an instance of the `BannerComponent`,
-adds a corresponding element to the test-runner DOM,
-and returns a [`ComponentFixture`](#component-fixture).
-
-
-
-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.
-
-
-
-{@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:
-
-
-
-
-#### _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:
-
-
-
-
-{@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:
-
-
-
-
-{@a debug-element}
-
-#### _DebugElement_
-
-The Angular _fixture_ provides the component's element directly through the `fixture.nativeElement`.
-
-
-
-
-This is actually a convenience method, implemented as `fixture.debugElement.nativeElement`.
-
-
-
-
-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`:
-
-
-
-
-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.
-
-
-
-
-{@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:
-
-
-
-
-The following example re-implements the previous test with
-`DebugElement.query()` and the browser's `By.css` method.
-
-
-
-
-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.
-
-` element
-that wraps the _title_ property interpolation binding.
-
-You update the `beforeEach` to find that element with a standard HTML `querySelector`
-and assign it to the `h1` variable.
-
-` like this:
-
-
-
-
-_That test fails_ with the message:
-
-```javascript
-expected '' to contain 'Test Tour of Heroes'.
-```
-
-Binding happens when Angular performs **change detection**.
-
-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; a fact confirmed in the revised test:
-
-` have the expected title.
-
-
-
-
-Delayed change detection is intentional and useful.
-It gives the tester an opportunity to inspect and change the state of
-the component _before Angular initiates data binding and calls [lifecycle hooks](guide/lifecycle-hooks)_.
-
-Here's another test that changes the component's `title` property _before_ calling `fixture.detectChanges()`.
-
-
-
-
-{@a auto-detect-changes}
-
-#### Automatic change detection
-
-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:
-
-
-
-Rather than wonder when the test fixture will or won't perform change detection,
-the samples in this guide _always call_ `detectChanges()` _explicitly_.
-There is no harm in calling `detectChanges()` more often than is strictly necessary.
-
-
-
-
-Error: This test module uses the component BannerComponent
-which is using a "templateUrl" or "styleUrls", but they were never compiled.
-Please call "TestBed.compileComponents" before your test.
-
-
-You get this test failure message when the runtime environment
-compiles the source code _during the tests themselves_.
-
-To correct the problem, call `compileComponents()` as explained [below](#compile-components).
-
-{@a component-with-dependency}
-
-### Component with a dependency
-
-Components often have service dependencies.
-
-The `WelcomeComponent` displays a welcome message to the logged in user.
-It knows who the user is based on a property of the injected `UserService`:
-
-
-
-
-{@a testbed-inject}
-
-#### _TestBed.inject()_
-
-You _may_ also be able to get the service from the root injector via `TestBed.inject()`.
-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.
-
-In this test suite, the _only_ provider of `UserService` is the root testing module,
-so it is safe to call `TestBed.inject()` as follows:
-
-
-
-
-
-
-For a use case in which `TestBed.inject()` does not work,
-see the [_Override component providers_](#component-override) section that
-explains when and why you must get the service from the component's injector instead.
-
-
-
-{@a welcome-spec-setup}
-
-#### Final setup and tests
-
-Here's the complete `beforeEach()`, using `TestBed.inject()`:
-
-
-
-The second parameter to the Jasmine matcher (e.g., `'expected name'`) is an optional failure label.
-If the expectation fails, Jasmine appends this label to the expectation failure message.
-In a spec with multiple expectations, it can help clarify what went wrong and which expectation failed.
-
-
-
-The remaining tests confirm the logic of the component when the service returns different values.
-The second test validates the effect of changing the user name.
-The third test checks that the component displays the proper message when there is no logged-in user.
-
-
-
-
-The spy is designed such that any call to `getQuote` receives an observable with a test quote.
-Unlike the real `getQuote()` method, this spy bypasses the server
-and returns a synchronous observable whose value is available immediately.
-
-You can write many useful tests with this spy, even though its `Observable` is synchronous.
-
-{@a sync-tests}
-
-#### Synchronous tests
-
-A key advantage of a synchronous `Observable` is that
-you can often turn asynchronous processes into synchronous tests.
-
-
-
-
-Because the spy result returns synchronously, the `getQuote()` method updates
-the message on screen immediately _after_
-the first change detection cycle during which Angular calls `ngOnInit`.
-
-You're not so lucky when testing the error path.
-Although the service spy will return an error synchronously,
-the component method calls `setTimeout()`.
-The test must wait at least one full turn of the JavaScript engine before the
-value becomes available. The test must become _asynchronous_.
-
-{@a fake-async}
-
-#### Async test with _fakeAsync()_
-
-To use `fakeAsync()` functionality, you must import `zone.js/dist/zone-testing` in your test setup file.
-If you created your project with the Angular CLI, `zone-testing` is already imported in `src/test.ts`.
-
-The following test confirms the expected behavior when the service returns an `ErrorObservable`.
-
-
-
-
-Note that the `it()` function receives an argument of the following form.
-
-```javascript
-fakeAsync(() => { /* test body */ })
-```
-
-The `fakeAsync()` function enables a linear coding style by running the test body in a special `fakeAsync test zone`.
-The test body appears to be synchronous.
-There is no nested syntax (like a `Promise.then()`) to disrupt the flow of control.
-
-
-
-Limitation: The `fakeAsync()` function won't work if the test body makes an `XMLHttpRequest` (XHR) call.
-XHR calls within a test are rare, but if you need to call XHR, see [`async()`](#async), below.
-
-
-
-{@a tick}
-
-#### The _tick()_ function
-
-You do have to call [tick()](api/core/testing/tick) to advance the (virtual) clock.
-
-Calling [tick()](api/core/testing/tick) simulates the passage of time until all pending asynchronous activities finish.
-In this case, it waits for the error handler's `setTimeout()`.
-
-The [tick()](api/core/testing/tick) function accepts milliseconds and tickOptions as parameters, the millisecond (defaults to 0 if not provided) parameter represents how much the virtual clock advances. For example, if you have a `setTimeout(fn, 100)` in a `fakeAsync()` test, you need to use tick(100) to trigger the fn callback. The tickOptions is an optional parameter with a property called `processNewMacroTasksSynchronously` (defaults to true) represents whether to invoke new generated macro tasks when ticking.
-
-
-
-
-The [tick()](api/core/testing/tick) function is one of the Angular testing utilities that you import with `TestBed`.
-It's a companion to `fakeAsync()` and you can only call it within a `fakeAsync()` body.
-
-#### tickOptions
-
-
-
-
-In this example, we have a new macro task (nested setTimeout), by default, when we `tick`, the setTimeout `outside` and `nested` will both be triggered.
-
-
-
-
-And in some case, we don't want to trigger the new macro task when ticking, we can use `tick(milliseconds, {processNewMacroTasksSynchronously: false})` to not invoke new macro task.
-
-#### Comparing dates inside fakeAsync()
-
-`fakeAsync()` simulates passage of time, which allows you to calculate the difference between dates inside `fakeAsync()`.
-
-
-
-
-#### jasmine.clock with fakeAsync()
-
-Jasmine also provides a `clock` feature to mock dates. Angular automatically runs tests that are run after
-`jasmine.clock().install()` is called inside a `fakeAsync()` method until `jasmine.clock().uninstall()` is called. `fakeAsync()` is not needed and throws an error if nested.
-
-By default, this feature is disabled. To enable it, set a global flag before importing `zone-testing`.
-
-If you use the Angular CLI, configure this flag in `src/test.ts`.
-
-```
-(window as any)['__zone_symbol__fakeAsyncPatchLock'] = true;
-import 'zone.js/dist/zone-testing';
-```
-
-
-
-
-#### Using the RxJS scheduler inside fakeAsync()
-
-You can also use RxJS scheduler in `fakeAsync()` just like using `setTimeout()` or `setInterval()`, but you need to import `zone.js/dist/zone-patch-rxjs-fake-async` to patch RxJS scheduler.
-
-
-
-#### Support more macroTasks
-
-By default, `fakeAsync()` supports the following macro tasks.
-
-- `setTimeout`
-- `setInterval`
-- `requestAnimationFrame`
-- `webkitRequestAnimationFrame`
-- `mozRequestAnimationFrame`
-
-If you run other macro tasks such as `HTMLCanvasElement.toBlob()`, an _"Unknown macroTask scheduled in fake async test"_ error will be thrown.
-
-
-
-
-
-
-
-
-If you want to support such a case, you need to define the macro task you want to support in `beforeEach()`.
-For example:
-
-
-
-
-Note that in order to make the `` element Zone.js-aware in your app, you need to import the `zone-patch-canvas` patch (either in `polyfills.ts` or in the specific file that uses ``):
-
-
-
-
-
-#### Async observables
-
-You might be satisfied with the test coverage of these tests.
-
-However, you might be troubled by the fact that the real service doesn't quite behave this way.
-The real service sends requests to a remote server.
-A server takes time to respond and the response certainly won't be available immediately
-as in the previous two tests.
-
-Your tests will reflect the real world more faithfully if you return an _asynchronous_ observable
-from the `getQuote()` spy like this.
-
-
-
-
-#### Async observable helpers
-
-The async observable was produced by an `asyncData` helper.
-The `asyncData` helper is a utility function that you'll have to write yourself, or you can copy this one from the sample code.
-
-
-
-
-This helper's observable emits the `data` value in the next turn of the JavaScript engine.
-
-The [RxJS `defer()` operator](http://reactivex.io/documentation/operators/defer.html) returns an observable.
-It takes a factory function that returns either a promise or an observable.
-When something subscribes to _defer_'s observable,
-it adds the subscriber to a new observable created with that factory.
-
-The `defer()` operator transforms the `Promise.resolve()` into a new observable that,
-like `HttpClient`, emits once and completes.
-Subscribers are unsubscribed after they receive the data value.
-
-There's a similar helper for producing an async error.
-
-
-
-
-#### More async tests
-
-Now that the `getQuote()` spy is returning async observables,
-most of your tests will have to be async as well.
-
-Here's a `fakeAsync()` test that demonstrates the data flow you'd expect
-in the real world.
-
-
-
-
-Notice that the quote element displays the placeholder value (`'...'`) after `ngOnInit()`.
-The first quote hasn't arrived yet.
-
-To flush the first quote from the observable, you call [tick()](api/core/testing/tick).
-Then call `detectChanges()` to tell Angular to update the screen.
-
-Then you can assert that the quote element displays the expected text.
-
-{@a async}
-
-#### Async test with _async()_
-
-To use `async()` functionality, you must import `zone.js/dist/zone-testing` in your test setup file.
-If you created your project with the Angular CLI, `zone-testing` is already imported in `src/test.ts`.
-
-The `fakeAsync()` utility function has a few limitations.
-In particular, it won't work if the test body makes an `XMLHttpRequest` (XHR) call.
-XHR calls within a test are rare so you can generally stick with [`fakeAsync()`](#fake-async).
-But if you ever do need to call `XMLHttpRequest`, you'll want to know about `async()`.
-
-
-
-The `TestBed.compileComponents()` method (see [below](#compile-components)) calls `XHR`
-to read external template and css files during "just-in-time" compilation.
-Write tests that call `compileComponents()` with the `async()` utility.
-
-
-
-Here's the previous `fakeAsync()` test, re-written with the `async()` utility.
-
-
-
-
-The `async()` utility hides some asynchronous boilerplate by arranging for the tester's code
-to run in a special _async test zone_.
-You don't need to pass Jasmine's `done()` into the test and call `done()` because it is `undefined` in promise or observable callbacks.
-
-But the test's asynchronous nature is revealed by the call to `fixture.whenStable()`,
-which breaks the linear flow of control.
-
-When using an `intervalTimer()` such as `setInterval()` in `async()`, remember to cancel the timer with `clearInterval()` after the test, otherwise the `async()` never ends.
-
-{@a when-stable}
-
-#### _whenStable_
-
-The test must wait for the `getQuote()` observable to emit the next quote.
-Instead of calling [tick()](api/core/testing/tick), it calls `fixture.whenStable()`.
-
-The `fixture.whenStable()` returns a promise that resolves when the JavaScript engine's
-task queue becomes empty.
-In this example, the task queue becomes empty when the observable emits the first quote.
-
-The test resumes within the promise callback, which calls `detectChanges()` to
-update the quote element with the expected text.
-
-{@a jasmine-done}
-
-#### Jasmine _done()_
-
-While the `async()` and `fakeAsync()` functions greatly
-simplify Angular asynchronous testing,
-you can still fall back to the traditional technique
-and pass `it` a function that takes a
-[`done` callback](https://jasmine.github.io/2.0/introduction.html#section-Asynchronous_Support).
-
-You can't call `done()` in `async()` or `fakeAsync()` functions, because the `done parameter`
-is `undefined`.
-
-Now you are responsible for chaining promises, handling errors, and calling `done()` at the appropriate moments.
-
-Writing test functions with `done()`, is more cumbersome than `async()`and `fakeAsync()`, but it is occasionally necessary when code involves the `intervalTimer()` like `setInterval`.
-
-Here are two more versions of the previous test, written with `done()`.
-The first one subscribes to the `Observable` exposed to the template by the component's `quote` property.
-
-
-
-The [discussion below](#routing-component) covers testing components that require the router.
-
-
-
-The immediate goal is to test the `DashboardHeroComponent`, not the `DashboardComponent`,
-so, try the second and third options.
-
-{@a dashboard-standalone}
-
-#### Test _DashboardHeroComponent_ stand-alone
-
-Here's the meat of the spec file setup.
-
-
-
-
-Because the [template](#dashboard-hero-component) passes the hero name through the Angular `UpperCasePipe`,
-the test must match the element value with the upper-cased name.
-
-
-
-This small test demonstrates how Angular tests can verify a component's visual
-representation—something not possible with
-[component class tests](#component-class-testing)—at
-low cost and without resorting to much slower and more complicated end-to-end tests.
-
-
-
-#### Clicking
-
-Clicking the hero should raise a `selected` event that
-the host component (`DashboardComponent` presumably) can hear:
-
-
-
-
-The component's `selected` property returns an `EventEmitter`,
-which looks like an RxJS synchronous `Observable` to consumers.
-The test subscribes to it _explicitly_ just as the host component does _implicitly_.
-
-If the component behaves as expected, clicking the hero's element
-should tell the component's `selected` property to emit the `hero` object.
-
-The test detects that event through its subscription to `selected`.
-
-{@a trigger-event-handler}
-
-#### _triggerEventHandler_
-
-The `heroDe` in the previous test is a `DebugElement` that represents the hero ``.
-
-It has Angular properties and methods that abstract interaction with the native element.
-This test calls the `DebugElement.triggerEventHandler` with the "click" event name.
-The "click" event binding responds by calling `DashboardHeroComponent.click()`.
-
-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.
-
-The test triggered a "click" event with a `null` event object.
-
-
-
-
-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 (if any) was pressed during the click.
-The `RouterLink` directive throws an error if the event object is missing.
-
-
-
-#### Click the element
-
-The following test alternative calls the native element's own `click()` method,
-which is perfectly fine for _this component_.
-
-
-
-
-{@a click-helper}
-
-#### _click()_ helper
-
-Clicking a button, an anchor, or an arbitrary HTML element is a common test task.
-
-Make that consistent and easy by encapsulating the _click-triggering_ process
-in a helper such as the `click()` function below:
-
-
-
-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.
-
-
-
-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.
-
-
-
-Here's the previous test, rewritten using the click helper.
-
-
-
-
-
-
-{@a component-inside-test-host}
-
-### Component inside a test host
-
-The previous tests played the role of the host `DashboardComponent` themselves.
-But does the `DashboardHeroComponent` work correctly when properly data-bound to a host component?
-
-You could test with the actual `DashboardComponent`.
-But doing so could require a lot of setup,
-especially when its template features an `*ngFor` repeater,
-other components, layout HTML, additional bindings,
-a constructor that injects multiple services,
-and it starts interacting with those services right away.
-
-Imagine the effort to disable these distractions, just to prove a point
-that can be made satisfactorily with a _test host_ like this one:
-
-
-
-This test host binds to `DashboardHeroComponent` as the `DashboardComponent` would
-but without the noise of the `Router`, the `HeroService`, or 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 will be able to easily check `selectedHero` to verify that the
-`DashboardHeroComponent.selected` event emitted the expected hero.
-
-The setup for the _test-host_ tests is similar to the setup for the stand-alone tests:
-
-
-
-This testing module configuration shows three important differences:
-
-1. It _declares_ both the `DashboardHeroComponent` and the `TestHostComponent`.
-1. It _creates_ the `TestHostComponent` instead of the `DashboardHeroComponent`.
-1. The `TestHostComponent` sets the `DashboardHeroComponent.hero` with a binding.
-
-The `createComponent` returns a `fixture` that holds an instance of `TestHostComponent` instead of an instance of `DashboardHeroComponent`.
-
-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:
-
-
-
-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.
-
-
-
-{@a routing-component}
-
-### Routing component
-
-A _routing component_ is a component that tells the `Router` to navigate to another component.
-The `DashboardComponent` is a _routing component_ because the user can
-navigate to the `HeroDetailComponent` by clicking on one of the _hero buttons_ on the dashboard.
-
-Routing is pretty complicated.
-Testing the `DashboardComponent` seemed daunting in part because it involves the `Router`,
-which it injects together with the `HeroService`.
-
-
-
-Mocking the `HeroService` with a spy is a [familiar story](#component-with-async-service).
-But the `Router` has a complicated API and is entwined with other services and application preconditions. Might it be difficult to mock?
-
-Fortunately, not in this case because the `DashboardComponent` isn't doing much with the `Router`
-
-
-
-
-This is often the case with _routing components_.
-As a rule you test the component, not the router,
-and care only if the component navigates with the right address under the given conditions.
-
-Providing a router spy for _this component_ test suite happens to be as easy
-as providing a `HeroService` spy.
-
-
-
-The following test clicks the displayed hero and confirms that
-`Router.navigateByUrl` is called with the expected url.
-
-
-
-{@a routed-component-w-param}
-
-### Routed components
-
-A _routed component_ is the destination of a `Router` navigation.
-It can be trickier to test, especially when the route to the component _includes parameters_.
-The `HeroDetailComponent` is a _routed component_ that is the destination of such a route.
-
-When a user clicks a _Dashboard_ hero, the `DashboardComponent` tells the `Router`
-to navigate to `heroes/:id`.
-The `:id` is a route parameter whose value is the `id` of the hero to edit.
-
-The `Router` matches that URL to a route to the `HeroDetailComponent`.
-It creates an `ActivatedRoute` object with the routing information and
-injects it into a new instance of the `HeroDetailComponent`.
-
-Here's the `HeroDetailComponent` constructor:
-
-
-
-The `HeroDetail` component needs the `id` parameter so it can fetch
-the corresponding hero via the `HeroDetailService`.
-The component has to get the `id` from the `ActivatedRoute.paramMap` property
-which is an `Observable`.
-
-It can't just reference the `id` property of the `ActivatedRoute.paramMap`.
-The component has to _subscribe_ to the `ActivatedRoute.paramMap` observable and be prepared
-for the `id` to change during its lifetime.
-
-
-
-
-
-The [ActivatedRoute in action](guide/router#activated-route-in-action) section of the [Router](guide/router) guide covers `ActivatedRoute.paramMap` in more detail.
-
-
-
-Tests can explore how the `HeroDetailComponent` responds to different `id` parameter values
-by manipulating the `ActivatedRoute` injected into the component's constructor.
-
-You know how to spy on the `Router` and a data service.
-
-You'll take a different approach with `ActivatedRoute` because
-
-- `paramMap` returns an `Observable` that can emit more than one value
- during a test.
-- You need the router helper function, `convertToParamMap()`, to create a `ParamMap`.
-- Other _routed component_ tests need a test double for `ActivatedRoute`.
-
-These differences argue for a re-usable stub class.
-
-#### _ActivatedRouteStub_
-
-The following `ActivatedRouteStub` class serves as a test double for `ActivatedRoute`.
-
-
-
-Consider placing such helpers in a `testing` folder sibling to the `app` folder.
-This sample puts `ActivatedRouteStub` in `testing/activated-route-stub.ts`.
-
-
-
-Consider writing a more capable version of this stub class with
-the [_marble testing library_](#marble-testing).
-
-
-
-{@a tests-w-test-double}
-
-#### Testing with _ActivatedRouteStub_
-
-Here's a test demonstrating the component's behavior when the observed `id` refers to an existing hero:
-
-
-
-
-
-The `createComponent()` method and `page` object are discussed [below](#page-object).
-Rely on your intuition for now.
-
-
-
-When the `id` cannot be found, the component should re-route to the `HeroListComponent`.
-
-The test suite setup provided the same router spy [described above](#routing-component) which spies on the router without actually navigating.
-
-This test expects the component to try to navigate to the `HeroListComponent`.
-
-
-
-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:
-
-
-
-
-
-### Nested component tests
-
-Component templates often have nested components, whose templates
-may contain more components.
-
-The component tree can be very deep and, most of the time, the nested components
-play no role in testing the component at the top of the tree.
-
-The `AppComponent`, for example, displays a navigation bar with anchors and their `RouterLink` directives.
-
-
-
-While the `AppComponent` _class_ is empty,
-you may want to write unit tests to confirm that the links are wired properly
-to the `RouterLink` directives, perhaps for the reasons [explained below](#why-stubbed-routerlink-tests).
-
-To validate the links, you don't need the `Router` to navigate and you don't
-need the `
` to mark where the `Router` inserts _routed components_.
-
-The `BannerComponent` and `WelcomeComponent`
-(indicated by `` and ``) are also irrelevant.
-
-Yet any test that creates the `AppComponent` in the DOM will also create instances of
-these three components and, if you let that happen,
-you'll have to configure the `TestBed` to create them.
-
-If you neglect to declare them, the Angular compiler won't recognize the
-``, ``, and `` tags in the `AppComponent` template
-and will throw an error.
-
-If you declare the real components, you'll also have to declare _their_ nested components
-and provide for _all_ services injected in _any_ component in the tree.
-
-That's too much effort just to answer a few simple questions about links.
-
-This section describes two techniques for minimizing the setup.
-Use them, alone or in combination, to stay focused on the testing the primary component.
-
-{@a stub-component}
-
-##### Stubbing unneeded components
-
-In the first technique, you create and declare stub versions of the components
-and directive that play little or no role in the tests.
-
-` element and the `routerLink` attribute
-because you declared a corresponding `AppComponent` and `RouterLinkDirectiveStub`
-in the `TestBed` configuration.
-
-But the compiler won't throw an error when it encounters ``, ``, or ``.
-It simply renders them as empty tags and the browser ignores them.
-
-You no longer need the stub components.
-
-#### Use both techniques together
-
-These are techniques for _Shallow Component Testing_ ,
-so-named because they reduce the visual surface of the component to just those elements
-in the component's template that matter for tests.
-
-The `NO_ERRORS_SCHEMA` approach is the easier of the two but don't overuse it.
-
-The `NO_ERRORS_SCHEMA` also prevents the compiler from telling you about the missing
-components and attributes that you omitted inadvertently or misspelled.
-You could waste hours chasing phantom bugs that the compiler would have caught in an instant.
-
-The _stub component_ approach has another advantage.
-While the stubs in _this_ example were empty,
-you could give them stripped-down templates and classes if your tests
-need to interact with them in some way.
-
-In practice you will combine the two techniques in the same setup,
-as seen in this example.
-
-` element
-and applies the `RouterLinkStubDirective` to the anchors with the `routerLink` attribute,
-but it ignores the `` and `` tags.
-
-` anchor elements in `AppComponent`) to the stub directive's `onClick` method.
-
-Clicking the anchor should trigger the `onClick()` method,
-which sets the stub's telltale `navigatedTo` property.
-Tests inspect `navigatedTo` to confirm that clicking the anchor
-set the expected route definition.
-
-
-
-Whether the router is configured properly to navigate with that route definition is a
-question for a separate set of tests.
-
-
-
-{@a by-directive}
-{@a inject-directive}
-
-#### _By.directive_ and injected directives
-
-A little more setup triggers the initial data binding and gets references to the navigation links:
-
-
-
-The "click" test _in this example_ is misleading.
-It tests the `RouterLinkDirectiveStub` 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.
-
-
-
-{@a why-stubbed-routerlink-tests}
-
-#### What good are these tests?
-
-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.
-
-
-
-A future guide update will explain how to write such
-tests with the `RouterTestingModule`.
-
-
-
-
-
-
-
-You can ignore this section if you _only_ run tests with the CLI `ng test` command
-because the CLI compiles the application before running the tests.
-
-
-
-If you run tests in a **non-CLI environment**, the tests may fail with a message like this one:
-
-
-Error: This test module uses the component BannerComponent
-which is using a "templateUrl" or "styleUrls", but they were never compiled.
-Please call "TestBed.compileComponents" before your test.
-
-
-The root of the problem is at least one of the components involved in the test
-specifies an external template or CSS file as
-the following version of the `BannerComponent` does.
-
-
-
-If you neglect to make the test function async
-(e.g., forget to use `async()` as described below),
-you'll see this error message
-
-
-Error: ViewDestroyedError: Attempt to use a destroyed view
-
-
-
-
-A typical approach is to divide the setup logic into two separate `beforeEach()` functions:
-
-1. An async `beforeEach()` that compiles the components
-1. A synchronous `beforeEach()` that performs the remaining setup.
-
-To follow this pattern, import the `async()` helper with the other testing symbols.
-
-
-
-
-#### The async _beforeEach_
-
-Write the first async `beforeEach` like this.
-
-
-
-Do not re-configure the `TestBed` after calling `compileComponents()`.
-
-
-
-Calling `compileComponents()` closes the current `TestBed` instance to further configuration.
-You cannot call any more `TestBed` configuration methods, not `configureTestingModule()`
-nor any of the `override...` methods. The `TestBed` throws an error if you try.
-
-Make `compileComponents()` the last step
-before calling `TestBed.createComponent()`.
-
-#### The synchronous _beforeEach_
-
-The second, synchronous `beforeEach()` contains the remaining setup steps,
-which include creating the component and querying for elements to inspect.
-
-
-
-
-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:
-
-- `NgModel` and friends in the `FormsModule` to enable two-way data binding.
-- The `TitleCasePipe` from the `shared` folder.
-- Router services (which these tests are stubbing).
-- Hero data access services (also stubbed).
-
-One approach is to configure the testing module from the individual pieces as in this example:
-
-
-
-Notice that the `beforeEach()` is asynchronous and calls `TestBed.compileComponents`
-because the `HeroDetailComponent` has an external template and css file.
-
-As explained in [_Calling compileComponents()_](#compile-components) above,
-these tests could be run in a non-CLI environment
-where Angular would have to compile them in the browser.
-
-
-
-#### Import a shared module
-
-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:
-
-
-
-Importing the component's feature module can be the easiest way to configure tests
-when there are many mutual dependencies within the module and
-the module is small, as feature modules tend to be.
-
-
-
-
-
-These tests could fail or timeout if the `HeroDetailService` made its own XHR calls to a remote server.
-There might not be a remote server to call.
-
-Fortunately, the `HeroDetailService` delegates responsibility for remote data access to an injected `HeroService`.
-
-
-
-What if you aren't so lucky. What if faking the `HeroService` is hard?
-What if `HeroDetailService` makes its own server requests?
-
-The `TestBed.overrideComponent` method can replace the component's `providers` with easy-to-manage _test doubles_
-as seen in the following setup variation:
-
-
- type MetadataOverride<T> = {
- add?: Partial<T>;
- remove?: Partial<T>;
- set?: Partial<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.
-
-The type parameter, `T`, is the kind of metadata you'd pass to the `@Component` decorator:
-
-
- selector?: string;
- template?: string;
- templateUrl?: string;
- providers?: any[];
- ...
-
-
-{@a spy-stub}
-
-#### Provide a _spy stub_ (_HeroDetailServiceSpy_)
-
-This example completely replaces the component's `providers` array with a new array containing a `HeroDetailServiceSpy`.
-
-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:
-
-
-
-
-
-The `
-
-Here are some tests of this component:
-
- `:not` pseudo-class
- in `By.css('h2:not([highlight])')` helps find `` 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 `` to get its `HighlightDirective` instance
- and its `defaultColor`.
-
-- `DebugElement.properties` affords access to the artificial custom property that is set by the directive.
-
-
-
-
-
-
- Function
-
-
- Description
-
-
-
-
-
- async
-
-
-
-
- Runs the body of a test (`it`) or setup (`beforeEach`) function within a special _async test zone_.
- See [discussion above](#async).
-
-
-
-
-
-
- fakeAsync
-
-
-
-
- Runs the body of a test (`it`) within a special _fakeAsync test zone_, enabling
- a linear control flow coding style. See [discussion above](#fake-async).
-
-
-
-
-
-
- tick
-
-
-
-
- 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_.
-
-
-
- The curious, dedicated reader might enjoy this lengthy blog post,
- ["_Tasks, microtasks, queues and schedules_"](https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/).
-
-
-
- Accepts an optional argument that moves the virtual clock forward
- by the specified number of milliseconds,
- clearing asynchronous activities scheduled within that timeframe.
- See [discussion above](#tick).
-
-
-
-
-
-
- inject
-
-
-
-
- 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](#get-injected-services).
-
-
-
-
-
-
- discardPeriodicTasks
-
-
-
-
- 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.
-
-
-
-
-
-
- flushMicrotasks
-
-
-
-
- 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.
-
-
-
-
-
-
- ComponentFixtureAutoDetect
-
-
-
-
- A provider token for a service that turns on [automatic change detection](#automatic-change-detection).
-
-
-
-
-
-
- getTestBed
-
-
-
-
- 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.
-
-
-
-
-
-
- type TestModuleMetadata = {
- providers?: any[];
- declarations?: any[];
- imports?: any[];
- schemas?: Array<SchemaMetadata | any[]>;
- };
-
-
-{@a metadata-override-object}
-
-Each override method takes a `MetadataOverride` where `T` is the kind of metadata
-appropriate to the method, that is, the parameter of an `@NgModule`,
-`@Component`, `@Directive`, or `@Pipe`.
-
-
- type MetadataOverride<T> = {
- add?: Partial<T>;
- remove?: Partial<T>;
- set?: Partial<T>;
- };
-
-
-{@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.
-
-
-
-
- Methods
-
-
- Description
-
-
-
-
-
- configureTestingModule
-
-
-
-
- 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.
-
-
-
-
-
-
- compileComponents
-
-
-
-
- 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](#compile-components).
-
- After calling `compileComponents`, the `TestBed` configuration is frozen for the duration of the current spec.
-
-
-
-
-
-
- createComponent
-
-
-
-
- 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.
-
-
-
-
-
-
- overrideModule
-
-
-
- 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.
-
-
-
-
-
-
- {@a testbed-inject}
- inject
-
-
-
-
- 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):
-
-
-
-
-
-
- {@a testbed-initTestEnvironment}
- initTestEnvironment
-
-
-
- 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-/testing/`.
-
-
-
-
-
-
- resetTestEnvironment
-
-
-
- Reset the initial test environment, including the default testing module.
-
-
-
-
-
-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`
-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.
-
-
-
-
- Properties
-
-
- Description
-
-
-
-
-
- componentInstance
-
-
-
-
- The instance of the component class created by `TestBed.createComponent`.
-
-
-
-
-
-
- debugElement
-
-
-
-
- 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).
-
-
-
-
-
-
- nativeElement
-
-
-
-
- The native DOM element at the root of the component.
-
-
-
-
-
-
- changeDetectorRef
-
-
-
-
- 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.
-
-
-
-
-
-{@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.
-
-
-
-
- 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`.
-
- Runs `checkNoChanges` afterwards to confirm that there are no circular updates unless
- called as `detectChanges(false)`;
-
-
-
-
-
-
- autoDetectChanges
-
-
-
-
- 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`.
-
-
-
-
-
-
- checkNoChanges
-
-
-
-
- Do a change detection run to make sure there are no pending changes.
- Throws an exceptions if there are.
-
-
-
-
-
- isStable
-
-
-
-
- If the fixture is currently _stable_, returns `true`.
- If there are async tasks that have not completed, returns `false`.
-
-
-
-
-
-
- whenStable
-
-
-
-
- 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](#when-stable).
-
-
-
-
-
-
- destroy
-
-
-
-
- Trigger component destruction.
-
-
-
-
-
-{@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:
-
-
-
-
- Member
-
-
- Description
-
-
-
-
-
- nativeElement
-
-
-
-
- The corresponding DOM element in the browser (null for WebWorkers).
-
-
-
-
-
-
- query
-
-
-
-
- Calling `query(predicate: Predicate)` returns the first `DebugElement`
- that matches the [predicate](#query-predicate) at any depth in the subtree.
-
-
-
-
-
-
- queryAll
-
-
-
-
- Calling `queryAll(predicate: Predicate)` returns all `DebugElements`
- that matches the [predicate](#query-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.
-
- 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
-
-
-
-
- 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
-
-
-
- The `DebugElement` parent. Null if this is the root element.
-
-
-
-
-
-
- name
-
-
-
-
- The element tag name, if it is an element.
-
-
-
-
-
-
- triggerEventHandler
-
-
-
- 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](#trigger-event-handler).
-
- If the event lacks a listener or there's some other problem,
- consider calling `nativeElement.dispatchEvent(eventObject)`.
-
-
-
-
-
-
- listeners
-
-
-
-
- The callbacks attached to the component's `@Output` properties and/or the element's event properties.
-
-
-
-
-
-
- providerTokens
-
-
-
-
- This component's injector lookup tokens.
- Includes the component itself plus the tokens that the component lists in its `providers` metadata.
-
-
-
-
-
-
- source
-
-
-
-
- Where to find this element in the source component template.
-
-
-
-
-
-
- references
-
-
-
-
- Dictionary of objects associated with template local variables (e.g. `#foo`),
- keyed by the local variable name.
-
-
-
-
-
-{@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":
-
-
If you create project with `Angular/CLI`, it is already imported in `src/test.ts`.
diff --git a/aio/content/navigation.json b/aio/content/navigation.json
index 5c40dc968f..7e883dc73a 100644
--- a/aio/content/navigation.json
+++ b/aio/content/navigation.json
@@ -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",
+
+