Technology	Purpose
Jasmine	The [Jasmine test framework](http://jasmine.github.io/2.4/introduction.html) provides everything needed to write basic tests. It ships with an HTML test runner that executes tests in the browser.
Angular testing utilities	Angular testing utilities create a test environment for the Angular application code under test. Use them to condition and control parts of the application as they interact _within_ the Angular environment.
Karma	The [karma test runner](https://karma-runner.github.io/1.0/index.html) is ideal for writing and running unit tests while developing the application. It can be an integral part of the project's development and continuous integration processes. This guide describes how to set up and run tests with karma.
Protractor	Use protractor to write and run _end-to-end_ (e2e) tests. End-to-end tests explore the application _as users experience it_. In e2e testing, one process runs the real application and a second process runs protractor tests that simulate user behavior and assert that the application respond in the browser as expected.

Technology

Purpose

Jasmine

The [Jasmine test framework](http://jasmine.github.io/2.4/introduction.html) provides everything needed to write basic tests. It ships with an HTML test runner that executes tests in the browser.

Angular testing utilities

Angular testing utilities create a test environment for the Angular application code under test. Use them to condition and control parts of the application as they interact _within_ the Angular environment.

Karma

The [karma test runner](https://karma-runner.github.io/1.0/index.html) is ideal for writing and running unit tests while developing the application. It can be an integral part of the project's development and continuous integration processes. This guide describes how to set up and run tests with karma.

Protractor

Use protractor to write and run _end-to-end_ (e2e) tests. End-to-end tests explore the application _as users experience it_. In e2e testing, one process runs the real application and a second process runs protractor tests that simulate user behavior and assert that the application respond in the browser as expected.

`. The test calls `triggerEventHandler` with the "click" event name. The "click" event binding responds by calling `DashboardHeroComponent.click()`. If the component behaves as expected, `click()` tells the component's `selected` property to emit the `hero` object, the test detects that value through its subscription to `selected`, and the test should pass. {@a trigger-event-handler} ### _triggerEventHandler_ The Angular `DebugElement.triggerEventHandler` can raise _any data-bound event_ by its _event name_. The second parameter is the event object passed to the handler. In this example, the test triggers 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 was pressed. This directive throws an error if the event object doesn't do this correctly. {@a click-helper} Clicking a button, an anchor, or an arbitrary HTML element is a common test task. Make that 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.

click() is not an Angular testing utility

The `click()` helper function is **not** one of the Angular testing utilities. It's a function defined in _this guide's sample code_. All of the sample tests use it. If you like it, add it to your own collection of helpers.

Here's the previous test, rewritten using this click helper.

{@a component-inside-test-host} ## Test a component inside a test host component In the previous approach, the tests themselves played the role of the host `DashboardComponent`. But does the `DashboardHeroComponent` work correctly when properly data-bound to a host component? Testing with the actual `DashboardComponent` host is doable but seems more trouble than its worth. It's easier to emulate the `DashboardComponent` host with a _test host_ like this one: The test host binds to `DashboardHeroComponent` as the `DashboardComponent` would but without the distraction of the `Router`, the `HeroService`, or even the `*ngFor` repeater. The test host sets the component's `hero` input property with its test hero. It binds the component's `selected` event with its `onSelected` handler, which records the emitted hero in its `selectedHero` property. Later, the tests check that property to verify that the `DashboardHeroComponent.selected` event emitted the right hero. The setup for the test-host tests is similar to the setup for the stand-alone tests: This testing module configuration shows two important differences: 1. It _declares_ both the `DashboardHeroComponent` and the `TestHostComponent`. 1. It _creates_ the `TestHostComponent` instead of the `DashboardHeroComponent`. 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. Back to top

{@a routed-component} ## Test a routed component Testing the actual `DashboardComponent` seemed daunting because it injects the `Router`. It also injects the `HeroService`, but faking that is a [familiar story](guide/testing#component-with-async-service). The `Router` has a complicated API and is entwined with other services and application preconditions. Fortunately, the `DashboardComponent` isn't doing much with the `Router` This is often the case. As a rule you test the component, not the router, and care only if the component navigates with the right address under the given conditions. Stubbing the router with a test implementation is an easy option. This should do the trick: Now set up the testing module with the test stubs for the `Router` and `HeroService`, and create a test instance of the `DashboardComponent` for subsequent testing. The following test clicks the displayed hero and confirms (with the help of a spy) that `Router.navigateByUrl` is called with the expected url. {@a inject} ### The _inject_ function Notice the `inject` function in the second `it` argument. The `inject` function is one of the Angular testing utilities. It injects services into the test function where you can alter, spy on, and manipulate them. The `inject` function has two parameters: 1. An array of Angular dependency injection tokens. 1. A test function whose parameters correspond exactly to each item in the injection token array.

inject uses the TestBed Injector

The `inject` function uses the current `TestBed` injector and can only return services provided at that level. It does not return services from component providers.

This example injects the `Router` from the current `TestBed` injector. That's fine for this test because the `Router` is, and must be, provided by the application root injector. If you need a service provided by the component's _own_ injector, call `fixture.debugElement.injector.get` instead:

Use the component's own injector to get the service actually injected into the component.

The `inject` function closes the current `TestBed` instance to further configuration. You cannot call any more `TestBed` configuration methods, not `configureTestingModule` nor any of the `override...` methods. The `TestBed` throws an error if you try.

Do not configure the `TestBed` after calling `inject`.

{@a routed-component-w-param} ### Test a routed component with parameters Clicking a _Dashboard_ hero triggers navigation to `heroes/:id`, where `:id` is a route parameter whose value is the `id` of the hero to edit. That URL matches a route to the `HeroDetailComponent`. The router pushes the `:id` token value into the `ActivatedRoute.params` _Observable_ property, Angular injects the `ActivatedRoute` into the `HeroDetailComponent`, and the component extracts the `id` so it can fetch the corresponding hero via the `HeroDetailService`. Here's the `HeroDetailComponent` constructor: `HeroDetailComponent` subscribes to `ActivatedRoute.params` changes in its `ngOnInit` method.

The expression after `route.params` chains an _Observable_ operator that _plucks_ the `id` from the `params` and then chains a `forEach` operator to subscribe to `id`-changing events. The `id` changes every time the user navigates to a different hero. The `forEach` passes the new `id` value to the component's `getHero` method (not shown) which fetches a hero and sets the component's `hero` property. If the`id` parameter is missing, the `pluck` operator fails and the `catch` treats failure as a request to edit a new hero. The [Router](guide/router#route-parameters) guide covers `ActivatedRoute.params` in more detail.

A test can explore how the `HeroDetailComponent` responds to different `id` parameter values by manipulating the `ActivatedRoute` injected into the component's constructor. By now you know how to stub the `Router` and a data service. Stubbing the `ActivatedRoute` follows the same pattern except for a complication: the `ActivatedRoute.params` is an _Observable_. {@a stub-observable} ### Create an _Observable_ test double The `hero-detail.component.spec.ts` relies on an `ActivatedRouteStub` to set `ActivatedRoute.params` values for each test. This is a cross-application, re-usable _test helper class_. Consider placing such helpers in a `testing` folder sibling to the `app` folder. This sample keeps `ActivatedRouteStub` in `testing/router-stubs.ts`: Notable features of this stub are: * The stub implements only two of the `ActivatedRoute` capabilities: `params` and `snapshot.params`. * _BehaviorSubject_ drives the stub's `params` _Observable_ and returns the same value to every `params` subscriber until it's given a new value. * The `HeroDetailComponent` chains its expressions to this stub `params` _Observable_ which is now under the tester's control. * Setting the `testParams` property causes the `subject` to push the assigned value into `params`. That triggers the `HeroDetailComponent` _params_ subscription, described above, in the same way that navigation does. * Setting the `testParams` property also updates the stub's internal value for the `snapshot` property to return.

The [_snapshot_](guide/router#snapshot "Router guide: snapshot") is another popular way for components to consume route parameters.

The router stubs in this guide are meant to inspire you. Create your own stubs to fit your testing needs.

{@a tests-w-observable-double} ### Testing with the _Observable_ test double 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 [in the next section](guide/testing#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 `RouterStub` [described above](guide/testing#routed-component) which spies on the router without actually navigating. This test supplies a "bad" id and expects the component to try to navigate. While this app doesn't have a route to the `HeroDetailComponent` that omits the `id` parameter, it might add such a route someday. The component should do something reasonable when there is no `id`. In this implementation, the component should create and display a new hero. New heroes have `id=0` and a blank `name`. This test confirms that the component behaves as expected:

Inspect and download _all_ of the guide's application test code with this live example.

{@a page-object} ## Use a _page_ object to simplify setup The `HeroDetailComponent` is a simple view with a title, two hero fields, and two buttons.

But there's already plenty of template complexity. To fully exercise the component, the test needs a lot of setup: * It must wait until a hero arrives before `*ngIf` allows any element in DOM. * It needs references to the title `` and the name `` so it can inspect their values. * It needs references to the two buttons so it can click them. * It needs spies for some of the component and router methods. Even a small form such as this one can produce a mess of tortured conditional setup and CSS element selection. Tame the madness with a `Page` class that simplifies access to component properties and encapsulates the logic that sets them. Here's the `Page` class for the `hero-detail.component.spec.ts` Now the important hooks for component manipulation and inspection are neatly organized and accessible from an instance of `Page`. A `createComponent` method creates a `page` object and fills in the blanks once the `hero` arrives. The [observable tests](guide/testing#tests-w-observable-double) in the previous section demonstrate how `createComponent` and `page` keep the tests short and _on message_. There are no distractions: no waiting for promises to resolve and no searching the DOM for element values to compare. Here are a few more `HeroDetailComponent` tests to drive the point home. Back to top

{@a import-module} ## Setup with module imports Earlier component tests configured the testing module with a few `declarations` like this: 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: 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: It's a bit tighter and smaller, with fewer import statements (not shown). {@a feature-module-import} ### Import the feature module The `HeroDetailComponent` is part of the `HeroModule` [Feature Module](guide/ngmodule#feature-modules) that aggregates more of the interdependent pieces including the `SharedModule`. Try a test configuration that imports the `HeroModule` like this one: That's _really_ crisp. Only the _test doubles_ in the `providers` remain. Even the `HeroDetailComponent` declaration is gone.

In fact, if you try to declare it, Angular throws an error because `HeroDetailComponent` is declared in both the `HeroModule` and the `DynamicTestModule` (the testing module).

Importing the component's feature module is often the easiest way to configure the tests, especially when the feature module is small and mostly self-contained, as feature modules should be.

{@a component-override} ## Override a component's providers The `HeroDetailComponent` provides its own `HeroDetailService`. It's not possible to stub the component's `HeroDetailService` in the `providers` of the `TestBed.configureTestingModule`. Those are providers for the _testing module_, not the component. They prepare the dependency injector at the _fixture level_. Angular creates the component with its _own_ injector, which is a _child_ of the fixture injector. It registers the component's providers (the `HeroDetailService` in this case) with the child injector. A test cannot get to child injector services from the fixture injector. And `TestBed.configureTestingModule` can't configure them either. Angular has been creating new instances of the real `HeroDetailService` all along!

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`. The [previous test configuration](guide/testing#feature-module-import) replaces the real `HeroService` with a `FakeHeroService` that intercepts server requests and fakes their responses.

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: Notice that `TestBed.configureTestingModule` no longer provides a (fake) `HeroService` because it's [not needed](guide/testing#spy-stub). {@a override-component-method} ### The _overrideComponent_ method Focus on the `overrideComponent` method. It takes two arguments: the component type to override (`HeroDetailComponent`) and an override metadata object. The [overide metadata object](guide/testing#metadata-override-object) is a generic defined as follows: type MetadataOverride = { add?: T; remove?: T; set?: T; }; A metadata override object can either add-and-remove elements in metadata properties or completely reset those properties. This example resets the component's `providers` metadata. 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: {@a override-tests} ### The override tests Now the tests can control the component's hero directly by manipulating the spy-stub's `testHero` and confirm that service methods were called. {@a more-overrides} ### More overrides The `TestBed.overrideComponent` method can be called multiple times for the same or different components. The `TestBed` offers similar `overrideDirective`, `overrideModule`, and `overridePipe` methods for digging into and replacing parts of these other classes. Explore the options and combinations on your own. Back to top

{@a router-outlet-component} ## Test a _RouterOutlet_ component The `AppComponent` displays routed components in a ``. It also displays a navigation bar with anchors and their `RouterLink` directives. {@a app-component-html} The component class does nothing. Unit tests can confirm that the anchors are wired properly without engaging the router. See why this is worth doing [below](guide/testing#why-stubbed-routerlink-tests). {@a stub-component} ### Stubbing unneeded components The test setup should look familiar. The `AppComponent` is the declared test subject. The setup extends the default testing module with one real component (`BannerComponent`) and several stubs. * `BannerComponent` is simple and harmless to use as is. * The real `WelcomeComponent` has an injected service. `WelcomeStubComponent` is a placeholder with no service to worry about. * The real `RouterOutlet` is complex and errors easily. The `RouterOutletStubComponent` (in `testing/router-stubs.ts`) is safely inert. The component stubs are essential. Without them, the Angular compiler doesn't recognize the `` and `` tags and throws an error. {@a router-link-stub} ### Stubbing the _RouterLink_ The `RouterLinkStubDirective` contributes substantively to the test: The `host` metadata property wires the click event of the host element (the ``) to the directive's `onClick` method. The URL bound to the `[routerLink]` attribute flows to the directive's `linkParams` property. Clicking the anchor should trigger the `onClick` method which sets the telltale `navigatedTo` property. Tests can inspect that property to confirm the expected _click-to-navigation_ behavior. {@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: Two points of special interest: 1. You can locate elements _by directive_, using `By.directive`, not just by css selectors. 1. You can use the component's dependency injector to get an attached directive because Angular always adds attached directives to the component's injector. {@a app-component-tests} Here are some tests that leverage this setup:

The "click" test _in this example_ is worthless. It works hard to appear useful when in fact it tests the `RouterLinkStubDirective` rather than the _component_. This is a common failing of directive stubs. It has a legitimate purpose in this guide. It demonstrates how to find a `RouterLink` element, click it, and inspect a result, without engaging the full router machinery. This is a skill you may need to test a more sophisticated component, one that changes the display, re-calculates parameters, or re-arranges navigation options when the user clicks the link.

{@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`.

{@a shallow-component-test} ## "Shallow component tests" with *NO\_ERRORS\_SCHEMA* The [previous setup](guide/testing#stub-component) declared the `BannerComponent` and stubbed two other components for _no reason other than to avoid a compiler error_. Without them, the Angular compiler doesn't recognize the ``, `` and `` tags in the [_app.component.html_](guide/testing#app-component-html) template and throws an error. Add `NO_ERRORS_SCHEMA` to the testing module's `schemas` metadata to tell the compiler to ignore unrecognized elements and attributes. You no longer have to declare irrelevant components and directives. These tests are ***shallow*** because they only "go deep" into the components you want to test. Here is a setup, with `import` statements, that demonstrates the improved simplicity of _shallow_ tests, relative to the stubbing setup.

The _only_ declarations are the _component-under-test_ (`AppComponent`) and the `RouterLinkStubDirective` that contributes actively to the tests. The [tests in this example](guide/testing#app-component-tests) are unchanged.

_Shallow component tests_ with `NO_ERRORS_SCHEMA` greatly simplify unit testing of complex templates. However, the compiler no longer alerts you to mistakes such as misspelled or misused components and directives.

{@a attribute-directive} ## Test an attribute directive An _attribute directive_ modifies the behavior of an element, component or another directive. Its name reflects the way the directive is applied: as an attribute on a host element. The sample application's `HighlightDirective` sets the background color of an element based on either a data bound color or a default color (lightgray). It also sets a custom property of the element (`customProperty`) to `true` for no reason other than to show that it can. It's used throughout the application, perhaps most simply in the `AboutComponent`: Testing the specific use of the `HighlightDirective` within the `AboutComponent` requires only the techniques explored above (in particular the ["Shallow test"](guide/testing#shallow-component-test) approach). However, testing a single use case is unlikely to explore the full range of a directive's capabilities. Finding and testing all components that use the directive is tedious, brittle, and almost as unlikely to afford full coverage. [Isolated unit tests](guide/testing#isolated-unit-tests) might be helpful, but attribute directives like this one tend to manipulate the DOM. Isolated unit tests don't touch the DOM and, therefore, do not inspire confidence in the directive's efficacy. A better solution is to create an artificial test component that demonstrates all ways to apply the directive.

The `` case binds the `HighlightDirective` to the name of a color value in the input box. The initial value is the word "cyan" which should be the background color of the input box.

Here are some tests of this component: A few techniques are noteworthy: * The `By.directive` predicate is a great way to get the elements that have this directive _when their element types are unknown_. * The `: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. Back to top
{@a isolated-unit-tests} ## Isolated Unit Tests Testing applications with the help of the Angular testing utilities is the main focus of this guide. However, it's often more productive to explore the inner logic of application classes with _isolated_ unit tests that don't depend upon Angular. Such tests are often smaller and easier to read, write, and maintain. They don't carry extra baggage: * Import from the Angular test libraries. * Configure a module. * Prepare dependency injection `providers`. * Call `inject` or `async` or `fakeAsync`. They follow patterns familiar to test developers everywhere: * Exhibit standard, Angular-agnostic testing techniques. * Create instances directly with `new`. * Substitute test doubles (stubs, spys, and mocks) for the real dependencies.

Write both kinds of tests
Good developers write both kinds of tests for the same application part, often in the same spec file. Write simple _isolated_ unit tests to validate the part in isolation. Write _Angular_ tests to validate the part as it interacts with Angular, updates the DOM, and collaborates with the rest of the application.
{@a isolated-service-tests} ### Services Services are good candidates for isolated unit testing. Here are some synchronous and asynchronous unit tests of the `FancyService` written without assistance from Angular testing utilities. A rough line count suggests that these isolated unit tests are about 25% smaller than equivalent Angular tests. That's telling but not decisive. The benefit comes from reduced setup and code complexity. Compare these equivalent tests of `FancyService.getTimeoutValue`. They have about the same line-count, but the Angular-dependent version has more moving parts including a couple of utility functions (`async` and `inject`). Both approaches work and it's not much of an issue if you're using the Angular testing utilities nearby for other reasons. On the other hand, why burden simple service tests with added complexity? Pick the approach that suits you. {@a services-with-dependencies} ### Services with dependencies Services often depend on other services that Angular injects into the constructor. You can test these services _without_ the `TestBed`. In many cases, it's easier to create and _inject_ dependencies by hand. The `DependentService` is a simple example: It delegates its only method, `getValue`, to the injected `FancyService`. Here are several ways to test it. The first test creates a `FancyService` with `new` and passes it to the `DependentService` constructor. However, it's rarely that simple. The injected service can be difficult to create or control. You can mock the dependency, use a dummy value, or stub the pertinent service method with a substitute method that's easy to control. These _isolated_ unit testing techniques are great for exploring the inner logic of a service or its simple integration with a component class. Use the Angular testing utilities when writing tests that validate how a service interacts with components _within the Angular runtime environment_. {@a isolated-pipe-tests} ### Pipes Pipes are easy to test without the Angular testing utilities. A pipe class has one method, `transform`, that manipulates the input value into a transformed output value. The `transform` implementation rarely interacts with the DOM. Most pipes have no dependence on Angular other than the `@Pipe` metadata and an interface. Consider a `TitleCasePipe` that capitalizes the first letter of each word. Here's a naive implementation with a regular expression. Anything that uses a regular expression is worth testing thoroughly. Use simple Jasmine to explore the expected cases and the edge cases. {@a write-tests} ### Write Angular tests too These are tests of the pipe _in isolation_. They can't tell if the `TitleCasePipe` is working properly as applied in the application components. Consider adding component tests such as this one: {@a isolated-component-tests} ### Components Component tests typically examine how a component class interacts with its own template or with collaborating components. The Angular testing utilities are specifically designed to facilitate such tests. Consider this `ButtonComp` component. The following Angular test demonstrates that clicking a button in the template leads to an update of the on-screen message. The assertions verify that the data values flow from one HTML control (the `

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#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#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#tick).
`inject`	Injects one or more services from the current `TestBed` injector into a test function. See [above](guide/testing#inject).
`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#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.

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#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-get} `get`	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.get` method takes an optional second parameter, the object to return if Angular can't find the provider (`null` in this example): After calling `get`, the `TestBed` configuration is frozen for the duration of the current spec.
{@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.

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](guide/testing#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.

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#when-stable).
`destroy`	Trigger component destruction.

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](guide/testing#query-predicate) at any depth in the subtree.
`queryAll`	Calling `queryAll(predicate: Predicate)` returns all `DebugElements` that matches the [predicate](guide/testing#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#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.

File	Description
`karma.conf.js`	The karma configuration file that specifies which plug-ins to use, which application and test files to load, which browser(s) to use, and how to report test results. It loads three other setup files: * `systemjs.config.js` * `systemjs.config.extras.js` * `karma-test-shim.js`
`karma-test-shim.js`	This shim prepares karma specifically for the Angular test environment and launches karma itself. It loads the `systemjs.config.js` file as part of that process.
`systemjs.config.js`	[SystemJS](https://github.com/systemjs/systemjs/blob/master/README.md) loads the application and test files. This script tells SystemJS where to find those files and how to load them. It's the same version of `systemjs.config.js` you installed during [setup](guide/testing#setup).
`systemjs.config.extras.js`	An optional file that supplements the SystemJS configuration in `systemjs.config.js` with configuration for the specific needs of the application itself. A stock `systemjs.config.js` can't anticipate those needs. You fill the gaps here. The sample version for this guide adds the model barrel to the SystemJs `packages` configuration.

` tags. Use the fixture's `DebugElement` to `query` for the `