cargdev/angular
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: traducir guide/testing-utility-apis.md (#237)

Browse Source 
Co-authored-by: Michael Prentice <splaktar@gmail.com>
Co-authored-by: Gustavo Rodríguez <47954465+gustavguez@users.noreply.github.com>

Fix #231
This commit is contained in:
Clara 2021-04-28 04:31:40 +02:00 committed by GitHub
parent 0731c7f634
commit a2aa45d3c7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 1034 additions and 295 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -0,0 +1,794 @@
# Testing Utility APIs
This page describes the most useful Angular testing features.
The Angular testing utilities include the `TestBed`, the `ComponentFixture`, and a handful of functions that control the test environment.
The [_TestBed_](#testbed-api-summary) and [_ComponentFixture_](#component-fixture-api-summary) classes are covered separately.
Here's a summary of the stand-alone functions, in order of likely utility:
<table>
<tr>
<th>
Function
</th>
<th>
Description
</th>
</tr>
<tr>
<td style="vertical-align: top">
<code>async</code>
</td>
<td>
Runs the body of a test (`it`) or setup (`beforeEach`) function within a special _async test zone_.
See [discussion above](guide/testing-components-scenarios#waitForAsync).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>fakeAsync</code>
</td>
<td>
Runs the body of a test (`it`) within a special _fakeAsync test zone_, enabling
a linear control flow coding style. See [discussion above](guide/testing-components-scenarios#fake-async).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>tick</code>
</td>
<td>
Simulates the passage of time and the completion of pending asynchronous activities
by flushing both _timer_ and _micro-task_ queues within the _fakeAsync test zone_.
<div class="alert is-helpful">
The curious, dedicated reader might enjoy this lengthy blog post,
["_Tasks, microtasks, queues and schedules_"](https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/).
</div>
Accepts an optional argument that moves the virtual clock forward
by the specified number of milliseconds,
clearing asynchronous activities scheduled within that timeframe.
See [discussion above](guide/testing-components-scenarios#tick).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>inject</code>
</td>
<td>
Injects one or more services from the current `TestBed` injector into a test function.
It cannot inject a service provided by the component itself.
See discussion of the [debugElement.injector](guide/testing-components-scenarios#get-injected-services).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>discardPeriodicTasks</code>
</td>
<td>
When a `fakeAsync()` test ends with pending timer event _tasks_ (queued `setTimeOut` and `setInterval` callbacks),
the test fails with a clear error message.
In general, a test should end with no queued tasks.
When pending timer tasks are expected, call `discardPeriodicTasks` to flush the _task_ queue
and avoid the error.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>flushMicrotasks</code>
</td>
<td>
When a `fakeAsync()` test ends with pending _micro-tasks_ such as unresolved promises,
the test fails with a clear error message.
In general, a test should wait for micro-tasks to finish.
When pending microtasks are expected, call `flushMicrotasks` to flush the _micro-task_ queue
and avoid the error.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>ComponentFixtureAutoDetect</code>
</td>
<td>
A provider token for a service that turns on [automatic change detection](guide/testing-components-scenarios#automatic-change-detection).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>getTestBed</code>
</td>
<td>
Gets the current instance of the `TestBed`.
Usually unnecessary because the static class methods of the `TestBed` class are typically sufficient.
The `TestBed` instance exposes a few rarely used members that are not available as
static methods.
</td>
</tr>
</table>
<hr>
{@a testbed-class-summary}
## _TestBed_ class summary
The `TestBed` class is one of the principal Angular testing utilities.
Its API is quite large and can be overwhelming until you've explored it,
a little at a time. Read the early part of this guide first
to get the basics before trying to absorb the full API.
The module definition passed to `configureTestingModule`
is a subset of the `@NgModule` metadata properties.
<code-example language="javascript">
type TestModuleMetadata = {
providers?: any[];
declarations?: any[];
imports?: any[];
schemas?: Array&lt;SchemaMetadata | any[]&gt;;
};
</code-example>
{@a metadata-override-object}
Each override method takes a `MetadataOverride<T>` where `T` is the kind of metadata
appropriate to the method, that is, the parameter of an `@NgModule`,
`@Component`, `@Directive`, or `@Pipe`.
<code-example language="javascript">
type MetadataOverride&lt;T&gt; = {
add?: Partial&lt;T&gt;;
remove?: Partial&lt;T&gt;;
set?: Partial&lt;T&gt;;
};
</code-example>
{@a testbed-methods}
{@a testbed-api-summary}
The `TestBed` API consists of static class methods that either update or reference a _global_ instance of the `TestBed`.
Internally, all static methods cover methods of the current runtime `TestBed` instance,
which is also returned by the `getTestBed()` function.
Call `TestBed` methods _within_ a `beforeEach()` to ensure a fresh start before each individual test.
Here are the most important static methods, in order of likely utility.
<table>
<tr>
<th>
Methods
</th>
<th>
Description
</th>
</tr>
<tr>
<td style="vertical-align: top">
<code>configureTestingModule</code>
</td>
<td>
The testing shims (`karma-test-shim`, `browser-test-shim`)
establish the [initial test environment](guide/testing) and a default testing module.
The default testing module is configured with basic declaratives and some Angular service substitutes that every tester needs.
Call `configureTestingModule` to refine the testing module configuration for a particular set of tests
by adding and removing imports, declarations (of components, directives, and pipes), and providers.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>compileComponents</code>
</td>
<td>
Compile the testing module asynchronously after you've finished configuring it.
You **must** call this method if _any_ of the testing module components have a `templateUrl`
or `styleUrls` because fetching component template and style files is necessarily asynchronous.
See [above](guide/testing-components-scenarios#compile-components).
After calling `compileComponents`, the `TestBed` configuration is frozen for the duration of the current spec.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>createComponent<T></code>
</td>
<td>
Create an instance of a component of type `T` based on the current `TestBed` configuration.
After calling `compileComponent`, the `TestBed` configuration is frozen for the duration of the current spec.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>overrideModule</code>
</td>
<td>
Replace metadata for the given `NgModule`. Recall that modules can import other modules.
The `overrideModule` method can reach deeply into the current testing module to
modify one of these inner modules.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>overrideComponent</code>
</td>
<td>
Replace metadata for the given component class, which could be nested deeply
within an inner module.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>overrideDirective</code>
</td>
<td>
Replace metadata for the given directive class, which could be nested deeply
within an inner module.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>overridePipe</code>
</td>
<td>
Replace metadata for the given pipe class, which could be nested deeply
within an inner module.
</td>
</tr>
<tr>
<td style="vertical-align: top">
{@a testbed-inject}
<code>inject</code>
</td>
<td>
Retrieve a service from the current `TestBed` injector.
The `inject` function is often adequate for this purpose.
But `inject` throws an error if it can't provide the service.
What if the service is optional?
The `TestBed.inject()` method takes an optional second parameter,
the object to return if Angular can't find the provider
(`null` in this example):
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="testbed-get-w-null" header="app/demo/demo.testbed.spec.ts"></code-example>
After calling `TestBed.inject`, the `TestBed` configuration is frozen for the duration of the current spec.
</td>
</tr>
<tr>
<td style="vertical-align: top">
{@a testbed-initTestEnvironment}
<code>initTestEnvironment</code>
</td>
<td>
Initialize the testing environment for the entire test run.
The testing shims (`karma-test-shim`, `browser-test-shim`) call it for you
so there is rarely a reason for you to call it yourself.
You may call this method _exactly once_. If you must change
this default in the middle of your test run, call `resetTestEnvironment` first.
Specify the Angular compiler factory, a `PlatformRef`, and a default Angular testing module.
Alternatives for non-browser platforms are available in the general form
`@angular/platform-<platform_name>/testing/<platform_name>`.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>resetTestEnvironment</code>
</td>
<td>
Reset the initial test environment, including the default testing module.
</td>
</tr>
</table>
A few of the `TestBed` instance methods are not covered by static `TestBed` _class_ methods.
These are rarely needed.
{@a component-fixture-api-summary}
## The _ComponentFixture_
The `TestBed.createComponent<T>`
creates an instance of the component `T`
and returns a strongly typed `ComponentFixture` for that component.
The `ComponentFixture` properties and methods provide access to the component,
its DOM representation, and aspects of its Angular environment.
{@a component-fixture-properties}
### _ComponentFixture_ properties
Here are the most important properties for testers, in order of likely utility.
<table>
<tr>
<th>
Properties
</th>
<th>
Description
</th>
</tr>
<tr>
<td style="vertical-align: top">
<code>componentInstance</code>
</td>
<td>
The instance of the component class created by `TestBed.createComponent`.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>debugElement</code>
</td>
<td>
The `DebugElement` associated with the root element of the component.
The `debugElement` provides insight into the component and its DOM element during test and debugging.
It's a critical property for testers. The most interesting members are covered [below](#debug-element-details).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>nativeElement</code>
</td>
<td>
The native DOM element at the root of the component.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>changeDetectorRef</code>
</td>
<td>
The `ChangeDetectorRef` for the component.
The `ChangeDetectorRef` is most valuable when testing a
component that has the `ChangeDetectionStrategy.OnPush` method
or the component's change detection is under your programmatic control.
</td>
</tr>
</table>
{@a component-fixture-methods}
### _ComponentFixture_ methods
The _fixture_ methods cause Angular to perform certain tasks on the component tree.
Call these method to trigger Angular behavior in response to simulated user action.
Here are the most useful methods for testers.
<table>
<tr>
<th>
Methods
</th>
<th>
Description
</th>
</tr>
<tr>
<td style="vertical-align: top">
<code>detectChanges</code>
</td>
<td>
Trigger a change detection cycle for the component.
Call it to initialize the component (it calls `ngOnInit`) and after your
test code, change the component's data bound property values.
Angular can't see that you've changed `personComponent.name` and won't update the `name`
binding until you call `detectChanges`.
Runs `checkNoChanges` afterwards to confirm that there are no circular updates unless
called as `detectChanges(false)`;
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>autoDetectChanges</code>
</td>
<td>
Set this to `true` when you want the fixture to detect changes automatically.
When autodetect is `true`, the test fixture calls `detectChanges` immediately
after creating the component. Then it listens for pertinent zone events
and calls `detectChanges` accordingly.
When your test code modifies component property values directly,
you probably still have to call `fixture.detectChanges` to trigger data binding updates.
The default is `false`. Testers who prefer fine control over test behavior
tend to keep it `false`.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>checkNoChanges</code>
</td>
<td>
Do a change detection run to make sure there are no pending changes.
Throws an exceptions if there are.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>isStable</code>
</td>
<td>
If the fixture is currently _stable_, returns `true`.
If there are async tasks that have not completed, returns `false`.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>whenStable</code>
</td>
<td>
Returns a promise that resolves when the fixture is stable.
To resume testing after completion of asynchronous activity or
asynchronous change detection, hook that promise.
See [above](guide/testing-components-scenarios#when-stable).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>destroy</code>
</td>
<td>
Trigger component destruction.
</td>
</tr>
</table>
{@a debug-element-details}
#### _DebugElement_
The `DebugElement` provides crucial insights into the component's DOM representation.
From the test root component's `DebugElement` returned by `fixture.debugElement`,
you can walk (and query) the fixture's entire element and component subtrees.
Here are the most useful `DebugElement` members for testers, in approximate order of utility:
<table>
<tr>
<th>
Member
</th>
<th>
Description
</th>
</tr>
<tr>
<td style="vertical-align: top">
<code>nativeElement</code>
</td>
<td>
The corresponding DOM element in the browser (null for WebWorkers).
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>query</code>
</td>
<td>
Calling `query(predicate: Predicate<DebugElement>)` returns the first `DebugElement`
that matches the [predicate](#query-predicate) at any depth in the subtree.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>queryAll</code>
</td>
<td>
Calling `queryAll(predicate: Predicate<DebugElement>)` returns all `DebugElements`
that matches the [predicate](#query-predicate) at any depth in subtree.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>injector</code>
</td>
<td>
The host dependency injector.
For example, the root element's component instance injector.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>componentInstance</code>
</td>
<td>
The element's own component instance, if it has one.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>context</code>
</td>
<td>
An object that provides parent context for this element.
Often an ancestor component instance that governs this element.
When an element is repeated within `*ngFor`, the context is an `NgForRow` whose `$implicit`
property is the value of the row instance value.
For example, the `hero` in `*ngFor="let hero of heroes"`.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>children</code>
</td>
<td>
The immediate `DebugElement` children. Walk the tree by descending through `children`.
<div class="alert is-helpful">
`DebugElement` also has `childNodes`, a list of `DebugNode` objects.
`DebugElement` derives from `DebugNode` objects and there are often
more nodes than elements. Testers can usually ignore plain nodes.
</div>
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>parent</code>
</td>
<td>
The `DebugElement` parent. Null if this is the root element.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>name</code>
</td>
<td>
The element tag name, if it is an element.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>triggerEventHandler</code>
</td>
<td>
Triggers the event by its name if there is a corresponding listener
in the element's `listeners` collection.
The second parameter is the _event object_ expected by the handler.
See [above](guide/testing-components-scenarios#trigger-event-handler).
If the event lacks a listener or there's some other problem,
consider calling `nativeElement.dispatchEvent(eventObject)`.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>listeners</code>
</td>
<td>
The callbacks attached to the component's `@Output` properties and/or the element's event properties.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>providerTokens</code>
</td>
<td>
This component's injector lookup tokens.
Includes the component itself plus the tokens that the component lists in its `providers` metadata.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>source</code>
</td>
<td>
Where to find this element in the source component template.
</td>
</tr>
<tr>
<td style="vertical-align: top">
<code>references</code>
</td>
<td>
Dictionary of objects associated with template local variables (e.g. `#foo`),
keyed by the local variable name.
</td>
</tr>
</table>
{@a query-predicate}
The `DebugElement.query(predicate)` and `DebugElement.queryAll(predicate)` methods take a
predicate that filters the source element's subtree for matching `DebugElement`.
The predicate is any method that takes a `DebugElement` and returns a _truthy_ value.
The following example finds all `DebugElements` with a reference to a template local variable named "content":
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="custom-predicate" header="app/demo/demo.testbed.spec.ts"></code-example>
The Angular `By` class has three static methods for common predicates:
- `By.all` - return all elements.
- `By.css(selector)` - return elements with matching CSS selectors.
- `By.directive(directive)` - return elements that Angular matched to an instance of the directive class.
<code-example path="testing/src/app/hero/hero-list.component.spec.ts" region="by" header="app/hero/hero-list.component.spec.ts"></code-example>
<hr>

351
aio/content/guide/testing-utility-apis.md
View File

@ -1,22 +1,24 @@
# Testing Utility APIs # APIs de Utilidades de Testing
This page describes the most useful Angular testing features. Esta página describe las funciones de testing más útiles de Angular
The Angular testing utilities include the `TestBed`, the `ComponentFixture`, and a handful of functions that control the test environment. Las funciones de testing de Angular incluyen la `TestBed` , el `ComponentFixture` y varias funciones que controlan el medio de pruebas
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: Las clases [_TestBed_](#testbed-api-summary) y [_ComponentFixture_](#component-fixture-api-summary) se tratan aparte.
Este es un resumen de todas las funciones autocontenidas, en orden de posible utilidad:
<table> <table>
<tr> <tr>
<th> <th>
Function Función
</th> </th>
<th> <th>
Description Descripción
</th> </th>
</tr> </tr>
<tr> <tr>
<td style="vertical-align: top"> <td style="vertical-align: top">
<code>async</code> <code>async</code>
@ -24,8 +26,8 @@ Here's a summary of the stand-alone functions, in order of likely utility:
<td> <td>
Runs the body of a test (`it`) or setup (`beforeEach`) function within a special _async test zone_. Ejecuta el conjunto de una función test (`it`) o setup (`beforeEach`) desde una _zona de pruebas asíncrona_
See [discussion above](guide/testing-components-scenarios#waitForAsync). Consulta [esta discusión](guide/testing-components-scenarios#waitForAsync).
</td> </td>
</tr> </tr>
@ -37,8 +39,8 @@ Here's a summary of the stand-alone functions, in order of likely utility:
<td> <td>
Runs the body of a test (`it`) within a special _fakeAsync test zone_, enabling Ejecuta el conjunto de un test (`it`) desde una _zona falsa de pruebas asíncrona_ especial, permitiendo un estilo de código de flujo de control lineal.
a linear control flow coding style. See [discussion above](guide/testing-components-scenarios#fake-async). Consulta [esta discusión](guide/testing-components-scenarios#fake-async).
</td> </td>
</tr> </tr>
@ -50,20 +52,17 @@ Here's a summary of the stand-alone functions, in order of likely utility:
<td> <td>
Simulates the passage of time and the completion of pending asynchronous activities Simula el paso del tiempo y completar actividades asíncronas pendientes haciendo flush tanto en el _cronómetro_ como en la _cola de micro-tareas_ desde la _zona falsa de pruebas asíncronas_
by flushing both _timer_ and _micro-task_ queues within the _fakeAsync test zone_.
<div class="alert is-helpful"> <div class="alert is-helpful">
Algún lector curioso y dedicado quizá disfrute de la lectura de esta extensa publicación en un blog:
The curious, dedicated reader might enjoy this lengthy blog post,
["_Tasks, microtasks, queues and schedules_"](https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/). ["_Tasks, microtasks, queues and schedules_"](https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/).
</div> </div>
Accepts an optional argument that moves the virtual clock forward Acepta un argumento adicionar que adelanta el reloj virtual según el número especificado de milisegundos, despejando las actividades asíncronas planeadas para ese bloque de tiempo
by the specified number of milliseconds,
clearing asynchronous activities scheduled within that timeframe. Consulta [esta discusión](guide/testing-components-scenarios#tick).
See [discussion above](guide/testing-components-scenarios#tick).
</td> </td>
</tr> </tr>
@ -75,9 +74,9 @@ Here's a summary of the stand-alone functions, in order of likely utility:
<td> <td>
Injects one or more services from the current `TestBed` injector into a test function. Inyecta uno o más servicios desde la `TestBed` inyectora actual hacia una función de test.
It cannot inject a service provided by the component itself. No puede inyectar un servicio proveído por el componente en sí.
See discussion of the [debugElement.injector](guide/testing-components-scenarios#get-injected-services). Consulta [debugElement.injector](guide/testing-components-scenarios#get-injected-services).
</td> </td>
</tr> </tr>
@ -89,12 +88,9 @@ Here's a summary of the stand-alone functions, in order of likely utility:
<td> <td>
When a `fakeAsync()` test ends with pending timer event _tasks_ (queued `setTimeOut` and `setInterval` callbacks), Cuando un `fakeAsync()` test finaliza con tareas cronometradas pendientes (llamadas a `setTimeOut` y `setInterval` en cola), el test finaliza con un mensaje de error vacío.
the test fails with a clear error message.
In general, a test should end with no queued tasks. En general, un test debería finalizar sin tareas en cola. Cuando esperamos tareas cronometradas pendientes, llamamos a `discardPeriodicTasks` para hacer flush a la cola de tareas y evitar el error.
When pending timer tasks are expected, call `discardPeriodicTasks` to flush the _task_ queue
and avoid the error.
</td> </td>
</tr> </tr>
@ -105,13 +101,9 @@ Here's a summary of the stand-alone functions, in order of likely utility:
</td> </td>
<td> <td>
Cuando un test `fakeAsync()` finaliza con micro-tareas pendientes como promesas sin resolver, el test finaliza con un mensaje de error vacío
When a `fakeAsync()` test ends with pending _micro-tasks_ such as unresolved promises, En general, un test debería esperar a que acaben las micro-tareas. Cuando quedan micro-tareas pendientes en cola, llamamos a `flushMicrotasks` para hacer flush a la cola de micro-tareas y evitar el error.
the test fails with a clear error message.
In general, a test should wait for micro-tasks to finish.
When pending microtasks are expected, call `flushMicrotasks` to flush the _micro-task_ queue
and avoid the error.
</td> </td>
</tr> </tr>
@ -122,8 +114,7 @@ Here's a summary of the stand-alone functions, in order of likely utility:
</td> </td>
<td> <td>
Un token del proveedor que inicia la [detección automática de cambios](guide/testing-components-scenarios#automatic-change-detection).
A provider token for a service that turns on [automatic change detection](guide/testing-components-scenarios#automatic-change-detection).
</td> </td>
</tr> </tr>
@ -135,10 +126,9 @@ Here's a summary of the stand-alone functions, in order of likely utility:
<td> <td>
Gets the current instance of the `TestBed`. Toma la instancia actual de la `TestBed`.
Usually unnecessary because the static class methods of the `TestBed` class are typically sufficient. Normalmente es innecesaria porque los métodos de clase estáticos de `TestBed` suelen ser suficientes.
The `TestBed` instance exposes a few rarely used members that are not available as La instancia de `TestBed` muestra algunos miembros menos comunes que no están disponibles como métodos estáticos
static methods.
</td> </td>
</tr> </tr>
@ -146,17 +136,13 @@ Here's a summary of the stand-alone functions, in order of likely utility:
<hr> <hr>
{@a testbed-class-summary} {@a resumen-clase-testbed}
## _TestBed_ class summary ## Resumen de la clase _TestBed_
The `TestBed` class is one of the principal Angular testing utilities. La clase `TestBed` es una de las utilidades de testing principales de Angular. Su API es bastante grande y puede ser sobrecogedora hasta que la has explorado, ve poco a poco. Puedes leer la parte inicial de esta guía primero para familiarizarte con lo básico antes de intentar aprender toda la API.
Its API is quite large and can be overwhelming until you've explored it,
a little at a time. Read the early part of this guide first
to get the basics before trying to absorb the full API.
The module definition passed to `configureTestingModule` La definición del módulo que pasamos a `configureTestingModule` es un subconjunto de las propiedades metadata de `@NgModule`.
is a subset of the `@NgModule` metadata properties.
<code-example language="javascript"> <code-example language="javascript">
type TestModuleMetadata = { type TestModuleMetadata = {
@ -169,9 +155,8 @@ is a subset of the `@NgModule` metadata properties.
{@a metadata-override-object} {@a metadata-override-object}
Each override method takes a `MetadataOverride<T>` where `T` is the kind of metadata Cada método de sobreescribir toma un `MetadataOverride<T>` donde `T` es el tipo de metadato apropiado para el método, es decir, el parámetro de un `@NgModule`,
appropriate to the method, that is, the parameter of an `@NgModule`, `@Component`, `@Directive`, o `@Pipe`.
`@Component`, `@Directive`, or `@Pipe`.
<code-example language="javascript"> <code-example language="javascript">
type MetadataOverride&lt;T&gt; = { type MetadataOverride&lt;T&gt; = {
@ -181,28 +166,28 @@ appropriate to the method, that is, the parameter of an `@NgModule`,
}; };
</code-example> </code-example>
{@a testbed-methods} {@a testbed-métodos}
{@a testbed-api-summary} {@a testbed-api-summary}
The `TestBed` API consists of static class methods that either update or reference a _global_ instance of the `TestBed`. La API `TestBed` consiste de métodos de clase estáticos que o actualizan o referencian una instancia global de `TestBed`.
Internally, all static methods cover methods of the current runtime `TestBed` instance, Internamente, todos los métodos estáticos cubren los métodos de la instancia `TestBed` actual, lo cual también es devuelto por la función `getTestBed()`.
which is also returned by the `getTestBed()` function.
Call `TestBed` methods _within_ a `beforeEach()` to ensure a fresh start before each individual test. Llama a los métodos `TestBed` *desde* un `beforeEach()` para asegurarte de tener un inicio en blanco antes de cada test individual.
Here are the most important static methods, in order of likely utility. Aquí están los métodos estáticos más importantes, en orden de posible utilidad.
<table> <table>
<tr> <tr>
<th> <th>
Methods Métodos
</th> </th>
<th> <th>
Description Descripción
</th> </th>
</tr> </tr>
<tr> <tr>
<td style="vertical-align: top"> <td style="vertical-align: top">
<code>configureTestingModule</code> <code>configureTestingModule</code>
@ -210,12 +195,10 @@ Here are the most important static methods, in order of likely utility.
<td> <td>
The testing shims (`karma-test-shim`, `browser-test-shim`) Los shims de prueba (`karma-test-shim, `browser-test-shim`) establecen el [medio de pruebas inicial](guide/testing)y un módulo de pruebas por defecto.
establish the [initial test environment](guide/testing) and a default testing module. El módulo de pruebas por defecto es configurado con declarativas básicas y algunos servicios sustitutos de Angular que cualquier tester necesitaría.
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 Llama a `configureTestingModule` para refinar la configuración del módulo de pruebas para un conjunto particular de tests, añadiendo o quitando importes, declaraciones (de componentes, directivas, pipes...) y proveedores.
by adding and removing imports, declarations (of components, directives, and pipes), and providers.
</td> </td>
</tr> </tr>
@ -227,12 +210,12 @@ Here are the most important static methods, in order of likely utility.
<td> <td>
Compile the testing module asynchronously after you've finished configuring it. Compila el módulo de testing de forma asíncrona después de que hayas finalizado configurándolo.
You **must** call this method if _any_ of the testing module components have a `templateUrl` Debes llamar este método si cualquiera de los componentes de módulo de testing tiene una `templateUrl` o `styleUrls`, porque traer templates de componentes y archivos de estilo es obligatoriamente asíncrono.
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. Consulta [aquí](guide/testing-components-scenarios#compile-components).
Después de llamar a `compileComponents`, la configuración de `TestBed` se congela durante la especificación actual.
</td> </td>
</tr> </tr>
@ -244,8 +227,8 @@ Here are the most important static methods, in order of likely utility.
<td> <td>
Create an instance of a component of type `T` based on the current `TestBed` configuration. Crea una instancia de un componente de tipo `T` basado en la configuración de la `TestBed` actual.
After calling `compileComponent`, the `TestBed` configuration is frozen for the duration of the current spec. Despuest de llamar a `compileComponent`, la configuración de `TestBed` se congela durante la especificación actual.
</td> </td>
</tr> </tr>
@ -256,9 +239,8 @@ Here are the most important static methods, in order of likely utility.
</td> </td>
<td> <td>
Replace metadata for the given `NgModule`. Recall that modules can import other modules. Reemplaza metadatos del `NgModule` proporcionado. Recuerde que los módulos pueden importar otros módulos.
The `overrideModule` method can reach deeply into the current testing module to El método `overrideModule` puede ir hasta el fondo del módulo testing actual para modificar alguno de estos módulos internos
modify one of these inner modules.
</td> </td>
</tr> </tr>
@ -270,8 +252,7 @@ Here are the most important static methods, in order of likely utility.
<td> <td>
Replace metadata for the given component class, which could be nested deeply Reemplaza metadatos para la clase componente dada, la cual puede estar anidada dentro de un módulo interno.
within an inner module.
</td> </td>
</tr> </tr>
@ -283,8 +264,7 @@ Here are the most important static methods, in order of likely utility.
<td> <td>
Replace metadata for the given directive class, which could be nested deeply Reemplaza metadatos para la clase directiva dada, la cual puede estar anidada dentro de un módulo interno.
within an inner module.
</td> </td>
</tr> </tr>
@ -295,8 +275,7 @@ Here are the most important static methods, in order of likely utility.
</td> </td>
<td> <td>
Replace metadata for the given pipe class, which could be nested deeply Reemplaza metadatos para la clase pipe dada, la cual puede estar anidada dentro de un módulo interno.
within an inner module.
</td> </td>
</tr> </tr>
@ -309,20 +288,17 @@ Here are the most important static methods, in order of likely utility.
<td> <td>
Retrieve a service from the current `TestBed` injector. Trae un servicio del inyector `TestBed` actual.
The `inject` function is often adequate for this purpose. La función `inject` normalmente es adecuada para esto, pero lanza un error si no puede proveer el servicio
But `inject` throws an error if it can't provide the service.
What if the service is optional? ¿Qué pasa si el servicio es opcional?
The `TestBed.inject()` method takes an optional second parameter, El método `TestBed.inject()` toma un segundo parámetro opcional, el objeto para devolver si Angular no encuentra el proveedor (nulo, en este ejemplo):
the object to return if Angular can't find the provider
(`null` in this example):
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="testbed-get-w-null" header="app/demo/demo.testbed.spec.ts"></code-example> <code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="testbed-get-w-null" header="app/demo/demo.testbed.spec.ts"></code-example>
After calling `TestBed.inject`, the `TestBed` configuration is frozen for the duration of the current spec. Después de llamar a `TestBed.inject`, la configuración de `TestBed` se congela durante la especificación actual.
</td> </td>
</tr> </tr>
@ -334,16 +310,14 @@ Here are the most important static methods, in order of likely utility.
</td> </td>
<td> <td>
Initialize the testing environment for the entire test run. Inicializa el medio de testing para todo el test run.
The testing shims (`karma-test-shim`, `browser-test-shim`) call it for you Los shims de pruebas (`karma-test-shim`, `browser-test-shim`) lo llaman por ti, así que no suele haber un motivo para usarlo.
so there is rarely a reason for you to call it yourself.
You may call this method _exactly once_. If you must change Puedes llamar este método _exactamente una vez_. Si debes cambiar este valor por defecto en mitad de un test run, utiliza `resetTestEnvironment` primero.
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. Especifica el compilador de fábrica Angular, un `PlatformRef` y un módulo por defecto de pruebas de Angular.
Alternatives for non-browser platforms are available in the general form Existen alternativas para plataformas no basadas en navegador en el formulario general siguiente:
`@angular/platform-<platform_name>/testing/<platform_name>`. `@angular/platform-<platform_name>/testing/<platform_name>`.
</td> </td>
@ -355,39 +329,35 @@ Here are the most important static methods, in order of likely utility.
</td> </td>
<td> <td>
Reset the initial test environment, including the default testing module. Resetea el medio de pruebas inicial, incluyendo el módulo de pruebas por defecto.
</td> </td>
</tr> </tr>
</table> </table>
A few of the `TestBed` instance methods are not covered by static `TestBed` _class_ methods. Algunos de los métodos de instancia de `TestBed` no son cubiertos por los métodos estáticos de clase de `TestBed`. Estos no suelen utilizarse.
These are rarely needed.
{@a component-fixture-api-summary} {@a component-fixture-api-summary}
## The _ComponentFixture_ ## El _ComponentFixture_
The `TestBed.createComponent<T>` `TestBed.createComponent<T>` crea una instancia de un componente `T` y devuelve un `ComponentFixture` fuertemente tipificado para ese componente
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, Las propiedades y métodos de `ComponentFixture` permiten acceso al componente, su representación DOM y algunos aspectos del medio Angular.
its DOM representation, and aspects of its Angular environment.
{@a component-fixture-properties} {@a componentes-fixture-propiedades}
### _ComponentFixture_ properties ### Propiedades de _ComponentFixture_
Here are the most important properties for testers, in order of likely utility. Aquí están las propiedades más importantes para testers, en orden de posible utilidad.
<table> <table>
<tr> <tr>
<th> <th>
Properties Propiedades
</th> </th>
<th> <th>
Description Descripción
</th> </th>
</tr> </tr>
@ -398,7 +368,7 @@ Here are the most important properties for testers, in order of likely utility.
<td> <td>
The instance of the component class created by `TestBed.createComponent`. La instancia de la clase componente creada por `TestBed.createComponent`.
</td> </td>
</tr> </tr>
@ -410,10 +380,11 @@ Here are the most important properties for testers, in order of likely utility.
<td> <td>
The `DebugElement` associated with the root element of the component. El `DebugElement` asociado con el elemento raíz del componente.
The `debugElement` provides insight into the component and its DOM element during test and debugging. El `DebugElement` da información sobre el componente y su elemento DOM durante el test y debug.
It's a critical property for testers. The most interesting members are covered [below](#debug-element-details).
Es una propiedad crítica para los testers. Los miembros más interesantes están cubiertos [aquí](#debug-element-details).
</td> </td>
</tr> </tr>
@ -425,7 +396,7 @@ Here are the most important properties for testers, in order of likely utility.
<td> <td>
The native DOM element at the root of the component. El elemento DOM nativo en la raíz del componente.
</td> </td>
</tr> </tr>
@ -437,35 +408,33 @@ Here are the most important properties for testers, in order of likely utility.
<td> <td>
The `ChangeDetectorRef` for the component. El `ChangeDetectorRef` para el componente.
The `ChangeDetectorRef` is most valuable when testing a El `ChangeDetectorRef` es más valioso cuando testeamos un componente que tiene el método`ChangeDetectionStrategy.OnPush` o cuando la detección de cambios del componente está bajo tu control programático.
component that has the `ChangeDetectionStrategy.OnPush` method
or the component's change detection is under your programmatic control.
</td> </td>
</tr> </tr>
</table> </table>
{@a component-fixture-methods} {@a componente-fixture-métodos}
### _ComponentFixture_ methods ### Métodos de _ComponentFixture_
The _fixture_ methods cause Angular to perform certain tasks on the component tree. Los métodos fixture hacen que Angular ejecute mejor ciertas tareas en el árbol de componentes. Llama a estos métodos para iniciar el comportamiento de Angular en respuesta a una acción de usuario simulada.
Call these method to trigger Angular behavior in response to simulated user action.
Here are the most useful methods for testers. Aquí están los métodos más útiles para los testers.
<table> <table>
<tr> <tr>
<th> <th>
Methods Métodos
</th> </th>
<th> <th>
Description Descripción
</th> </th>
</tr> </tr>
<tr> <tr>
<td style="vertical-align: top"> <td style="vertical-align: top">
<code>detectChanges</code> <code>detectChanges</code>
@ -473,15 +442,12 @@ Here are the most useful methods for testers.
<td> <td>
Trigger a change detection cycle for the component. Inicia un ciclo de detección de cambios para el componente.
Call it to initialize the component (it calls `ngOnInit`) and after your Llámalo para inicializar el componente (que llama a `ngOnInit`) y después de tu código de pruebas, cambia los valores de propiedad asociados a los datos de los componentes.
test code, change the component's data bound property values. Angular no puede ver que has cambiado `personComponent.name` y no actualizará el `name` hasta que llames a `detectChanges`.
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 Ejecuta `checkNoChanges` después para confirmar que no hay actualizaciones circulares, a no se que se llame así: `detectChanges(false)`
called as `detectChanges(false)`;
</td> </td>
</tr> </tr>
@ -493,16 +459,13 @@ Here are the most useful methods for testers.
<td> <td>
Poner esto a `true` cuando quieras que el fixture detecte los cambios automáticamente.
Set this to `true` when you want the fixture to detect changes automatically. Set this to `true` when you want the fixture to detect changes automatically.
When autodetect is `true`, the test fixture calls `detectChanges` immediately Cuando autodetect es `true`, el fixture de pruebas llama a `detectChanges` inmediatamente después de crear el componente. Después comprueba los eventos de zona pertinentes y llama a `detectChanges` de forma acorde.
after creating the component. Then it listens for pertinent zone events Cuando tu código de pruebas modifique los valores de propiedad de un componente de forma directa, probablemente tengas que llamar a `fixture.detectChanges` para iniciar las actualizaciones de unificación de datos.
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 El valor por defecto es `false`. Los testers que prefieren tener un control mayor sobre el comportamiento de pruebas suelen dejarlo en `false`.
tend to keep it `false`.
</td> </td>
</tr> </tr>
@ -514,8 +477,9 @@ Here are the most useful methods for testers.
<td> <td>
Do a change detection run to make sure there are no pending changes. Corre el programa para detectar cambios y asegurarse de que no hay cambios pendientes.
Throws an exceptions if there are. Lanza una excepción si los hay.
</td> </td>
</tr> </tr>
@ -526,8 +490,8 @@ Here are the most useful methods for testers.
<td> <td>
If the fixture is currently _stable_, returns `true`. Si el fixture es actualmente estable, devuelve `true`.
If there are async tasks that have not completed, returns `false`. Si hay tareas asíncronas no completadas, devuelve `false`.
</td> </td>
</tr> </tr>
@ -539,11 +503,11 @@ Here are the most useful methods for testers.
<td> <td>
Returns a promise that resolves when the fixture is stable. Devuelve una promesa que resuelve cuando el fixture es estable.
To resume testing after completion of asynchronous activity or Para volver al testing después de completar actividad asíncrona o detección de cambios asíncronos, añade esta promesa.
asynchronous change detection, hook that promise.
See [above](guide/testing-components-scenarios#when-stable). Consulta [aquí](guide/testing-components-scenarios#when-stable).
</td> </td>
</tr> </tr>
@ -555,30 +519,29 @@ Here are the most useful methods for testers.
<td> <td>
Trigger component destruction. Inicia la destrucción del componente
</td> </td>
</tr> </tr>
</table> </table>
{@a debug-element-details} {@a debug-elementos-detalles}
#### _DebugElement_ #### _DebugElement_
The `DebugElement` provides crucial insights into the component's DOM representation. El `DebugElement` proporciona información crucial para la representación DOM de los componentes.
From the test root component's `DebugElement` returned by `fixture.debugElement`, Desde el `DebugElement` del componente test raíz, devuelto por `fixture.debugElement`, puedes llegar a todo elemento y subárbol de componentes del fixture
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: Aquí están los miembros `DebugElement` más útiles para los testers, en orden de posible utilidad:
<table> <table>
<tr> <tr>
<th> <th>
Member Miembro
</th> </th>
<th> <th>
Description Descripción
</th> </th>
</tr> </tr>
@ -588,8 +551,7 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
</td> </td>
<td> <td>
El elemento DOM correspondiente en el navegador (nulo para WebWorkers).
The corresponding DOM element in the browser (null for WebWorkers).
</td> </td>
</tr> </tr>
@ -600,9 +562,7 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
</td> </td>
<td> <td>
Llamar a `query(predicate: Predicate<DebugElement>)` devuelbe el primer `DebugElement` que coincida con el [predicado](#query-predicate) a cualquier profundidad en el subárbol
Calling `query(predicate: Predicate<DebugElement>)` returns the first `DebugElement`
that matches the [predicate](#query-predicate) at any depth in the subtree.
</td> </td>
</tr> </tr>
@ -613,9 +573,7 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
</td> </td>
<td> <td>
Llamar a `queryAll(predicate: Predicate<DebugElement>)` devuelve todos los `DebugElements` que coincidan con el [predicado](#query-predicate) a cualquier profundidad en el subárbol
Calling `queryAll(predicate: Predicate<DebugElement>)` returns all `DebugElements`
that matches the [predicate](#query-predicate) at any depth in subtree.
</td> </td>
</tr> </tr>
@ -626,9 +584,7 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
</td> </td>
<td> <td>
El inyector de dependecia del host. Por ejemplo, el inyector de la instancia del componente del elemento
The host dependency injector.
For example, the root element's component instance injector.
</td> </td>
</tr> </tr>
@ -639,8 +595,7 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
</td> </td>
<td> <td>
La instancia del componente del propio elemento, si tiene.
The element's own component instance, if it has one.
</td> </td>
</tr> </tr>
@ -652,12 +607,10 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
<td> <td>
An object that provides parent context for this element. Un objeto que provee contexto del padre para este elemento.
Often an ancestor component instance that governs this element. En muchas ocasiones una instancia del componente ancestro gobierna este elemento.
When an element is repeated within `*ngFor`, the context is an `NgForRow` whose `$implicit` Cuando un elemento se repite en `*ngFor`, el contexto es un `NgForRow` cuya propiedad `$implicit` es el valor de la instancia de la fila. Por ejemplo, el `hero` en *ngFor="let hero of heroes"`.
property is the value of the row instance value.
For example, the `hero` in `*ngFor="let hero of heroes"`.
</td> </td>
</tr> </tr>
@ -669,13 +622,12 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
<td> <td>
The immediate `DebugElement` children. Walk the tree by descending through `children`. Los hijos `DebugElement` inmediatos. Recorre el árbol descendiendo a través de los hijos.
<div class="alert is-helpful"> <div class="alert is-helpful">
`DebugElement` also has `childNodes`, a list of `DebugNode` objects. `DebugElement` también tiene `childNodes`, una lista de objetos `DebugNode`.
`DebugElement` derives from `DebugNode` objects and there are often `DebugElement` deriva de los objetos `DebugNode` y suele haber más nodos que elementos. Los tester normalmente ignoran los nodos planos.
more nodes than elements. Testers can usually ignore plain nodes.
</div> </div>
</td> </td>
@ -687,7 +639,7 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
</td> </td>
<td> <td>
The `DebugElement` parent. Null if this is the root element. El `DebugElement` padre. Es nulo si este es el elemento raíz.
</td> </td>
</tr> </tr>
@ -698,8 +650,7 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
</td> </td>
<td> <td>
El tag name del elemento, si es que es un elemento.
The element tag name, if it is an element.
</td> </td>
</tr> </tr>
@ -710,13 +661,12 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
</td> </td>
<td> <td>
Triggers the event by its name if there is a corresponding listener Inicia el evento por su nombre si hay un receptor correspondiente en la colección `listeners` del elemento.
in the element's `listeners` collection. El segundo parámetro es el _objeto evento_ esperado por el handler.
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, Consulta [aquí](guide/testing-components-scenarios#trigger-event-handler).
consider calling `nativeElement.dispatchEvent(eventObject)`.
Si el evento no tiene un receptor o hay algún problema, considera llamar a `nativeElement.dispatchEvent(eventObject)`.
</td> </td>
</tr> </tr>
@ -728,7 +678,7 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
<td> <td>
The callbacks attached to the component's `@Output` properties and/or the element's event properties. Los callbacks insertados al `@Output` del componente, sus propiedades y/o las propiedades de evento del elemento.
</td> </td>
</tr> </tr>
@ -739,9 +689,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
</td> </td>
<td> <td>
Los token de búsqueda del inyector de este componente.
This component's injector lookup tokens. Include el componente en sí mismo además de los tokens que el componente lista en la parte "proveedores" de sus metadatos.
Includes the component itself plus the tokens that the component lists in its `providers` metadata.
</td> </td>
</tr> </tr>
@ -752,8 +701,7 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
</td> </td>
<td> <td>
Dónde encontrar este elemento en el componente template fuente.
Where to find this element in the source component template.
</td> </td>
</tr> </tr>
@ -764,9 +712,7 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
</td> </td>
<td> <td>
Diccionario de objetos asociados a variables locales template (e.g. `#foo`), acuñado por el nombre de la variable local
Dictionary of objects associated with template local variables (e.g. `#foo`),
keyed by the local variable name.
</td> </td>
</tr> </tr>
@ -774,21 +720,20 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
{@a query-predicate} {@a query-predicate}
The `DebugElement.query(predicate)` and `DebugElement.queryAll(predicate)` methods take a Los métodos `DebugElement.query(predicate)` y`DebugElement.queryAll(predicate)` toman un predicado que filtra el subárbol del elemento fuente para igualar a `DebugElement`.
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. El predicado es cualquier método que tome el `DebugElement` y devuelva un valor verdadero.
The following example finds all `DebugElements` with a reference to a template local variable named "content":
El siguiente ejemplo encuentra todos los `DebugElement` con una referencia a una variable local template llamada "content":
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="custom-predicate" header="app/demo/demo.testbed.spec.ts"></code-example> <code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="custom-predicate" header="app/demo/demo.testbed.spec.ts"></code-example>
The Angular `By` class has three static methods for common predicates: La clase Angular `By` tiene tres métodos estáticos para predicados comunes:
- `By.all` - return all elements. - `By.all` - devuelve todos los elementos
- `By.css(selector)` - return elements with matching CSS selectors. - `By.css(selector)` - devuelve los elementos con selectores CSS coincidentes
- `By.directive(directive)` - return elements that Angular matched to an instance of the directive class. - `By.directive(directive)` - devuelve elementos que Angular ha unido a una instancia de la clase directiva.
<code-example path="testing/src/app/hero/hero-list.component.spec.ts" region="by" header="app/hero/hero-list.component.spec.ts"></code-example> <code-example path="testing/src/app/hero/hero-list.component.spec.ts" region="by" header="app/hero/hero-list.component.spec.ts"></code-example>
<hr> <hr>