This page describes the most useful Angular testing features.
\nThe Angular testing utilities include the TestBed, the ComponentFixture, and a handful of functions that control the test environment.\nThe TestBed and ComponentFixture classes are covered separately.
Here's a summary of the stand-alone functions, in order of likely utility:
\n| \n Function\n | \n\n Description\n | \n
|---|---|
\n waitForAsync\n | \n \n Runs the body of a test ( | \n
\n fakeAsync\n | \n \n Runs the body of a test ( | \n
\n tick\n | \n \n Simulates the passage of time and the completion of pending asynchronous activities\nby flushing both timer and micro-task queues within the fakeAsync test zone. \n\n \nThe curious, dedicated reader might enjoy this lengthy blog post,\n\"Tasks, microtasks, queues and schedules\". \nAccepts an optional argument that moves the virtual clock forward\nby the specified number of milliseconds,\nclearing asynchronous activities scheduled within that timeframe.\nSee discussion above. \n | \n
\n inject\n | \n \n Injects one or more services from the current | \n
\n discardPeriodicTasks\n | \n \n When a In general, a test should end with no queued tasks.\nWhen pending timer tasks are expected, call | \n
\n flushMicrotasks\n | \n \n When a In general, a test should wait for micro-tasks to finish.\nWhen pending microtasks are expected, call | \n
\n ComponentFixtureAutoDetect\n | \n \n A provider token for a service that turns on automatic change detection. \n | \n
\n getTestBed\n | \n \n Gets the current instance of the | \n
The TestBed class is one of the principal Angular testing utilities.\nIts API is quite large and can be overwhelming until you've explored it,\na little at a time. Read the early part of this guide first\nto get the basics before trying to absorb the full API.
The module definition passed to configureTestingModule\nis a subset of the @NgModule metadata properties.
Each override method takes a MetadataOverride<T> where T is the kind of metadata\nappropriate to the method, that is, the parameter of an @NgModule,\n@Component, @Directive, or @Pipe.
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,\nwhich 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.
\n| \n Methods\n | \n\n Description\n | \n
|---|---|
\n configureTestingModule\n | \n \n The testing shims ( Call | \n
\n compileComponents\n | \n \n Compile the testing module asynchronously after you've finished configuring it.\nYou must call this method if any of the testing module components have a After calling | \n
\n createComponent\n | \n \n Create an instance of a component of type | \n
\n overrideModule\n | \n \n Replace metadata for the given | \n
\n overrideComponent\n | \n \n Replace metadata for the given component class, which could be nested deeply\nwithin an inner module. \n | \n
\n overrideDirective\n | \n \n Replace metadata for the given directive class, which could be nested deeply\nwithin an inner module. \n | \n
\n overridePipe\n | \n \n Replace metadata for the given pipe class, which could be nested deeply\nwithin an inner module. \n | \n
\n \n inject\n | \n \n Retrieve a service from the current The What if the service is optional? \n The After calling | \n
\n \n initTestEnvironment\n | \n \n Initialize the testing environment for the entire test run. \n The testing shims ( You may call this method exactly once. If you must change\nthis default in the middle of your test run, call Specify the Angular compiler factory, a | \n
\n resetTestEnvironment\n | \n \n Reset the initial test environment, including the default testing module. \n | \n
A few of the TestBed instance methods are not covered by static TestBed class methods.\nThese are rarely needed.
The TestBed.createComponent<T>\ncreates an instance of the component T\nand returns a strongly typed ComponentFixture for that component.
The ComponentFixture properties and methods provide access to the component,\nits DOM representation, and aspects of its Angular environment.
Here are the most important properties for testers, in order of likely utility.
\n| \n Properties\n | \n\n Description\n | \n
|---|---|
\n componentInstance\n | \n \n The instance of the component class created by | \n
\n debugElement\n | \n \n The The | \n
\n nativeElement\n | \n \n The native DOM element at the root of the component. \n | \n
\n changeDetectorRef\n | \n \n The The | \n
The fixture methods cause Angular to perform certain tasks on the component tree.\nCall these method to trigger Angular behavior in response to simulated user action.
\nHere are the most useful methods for testers.
\n| \n Methods\n | \n\n Description\n | \n
|---|---|
\n detectChanges\n | \n \n Trigger a change detection cycle for the component. \n Call it to initialize the component (it calls Runs | \n
\n autoDetectChanges\n | \n \n Set this to When autodetect is The default is | \n
\n checkNoChanges\n | \n \n Do a change detection run to make sure there are no pending changes.\nThrows an exceptions if there are. \n | \n
\n isStable\n | \n \n If the fixture is currently stable, returns | \n
\n whenStable\n | \n \n Returns a promise that resolves when the fixture is stable. \nTo resume testing after completion of asynchronous activity or\nasynchronous change detection, hook that promise.\nSee above. \n | \n
\n destroy\n | \n \n Trigger component destruction. \n | \n
The DebugElement provides crucial insights into the component's DOM representation.
From the test root component's DebugElement returned by fixture.debugElement,\nyou 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:
| \n Member\n | \n\n Description\n | \n
|---|---|
\n nativeElement\n | \n \n The corresponding DOM element in the browser (null for WebWorkers). \n | \n
\n query\n | \n \n Calling | \n
\n queryAll\n | \n \n Calling | \n
\n injector\n | \n \n The host dependency injector.\nFor example, the root element's component instance injector. \n | \n
\n componentInstance\n | \n \n The element's own component instance, if it has one. \n | \n
\n context\n | \n \n An object that provides parent context for this element.\nOften an ancestor component instance that governs this element. \n When an element is repeated within | \n
\n children\n | \n \n The immediate \n \n | \n
\n parent\n | \n \n The | \n
\n name\n | \n \n The element tag name, if it is an element. \n | \n
\n triggerEventHandler\n | \n \n Triggers the event by its name if there is a corresponding listener\nin the element's If the event lacks a listener or there's some other problem,\nconsider calling | \n
\n listeners\n | \n \n The callbacks attached to the component's | \n
\n providerTokens\n | \n \n This component's injector lookup tokens.\nIncludes the component itself plus the tokens that the component lists in its | \n
\n source\n | \n \n Where to find this element in the source component template. \n | \n
\n references\n | \n \n Dictionary of objects associated with template local variables (e.g. | \n
The DebugElement.query(predicate) and DebugElement.queryAll(predicate) methods take a\npredicate that filters the source element's subtree for matching DebugElement.
The predicate is any method that takes a DebugElement and returns a truthy value.\nThe following example finds all DebugElements with a reference to a template local variable named \"content\":
The Angular By class has three static methods for common predicates:
By.all - return all elements.By.css(selector) - return elements with matching CSS selectors.By.directive(directive) - return elements that Angular matched to an instance of the directive class.