# APIs de Utilidades de Testing Esta página describe las funciones de testing más útiles de Angular Las funciones de testing de Angular incluyen la `TestBed` , el `ComponentFixture` y varias funciones que controlan el medio de pruebas 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:
Función Descripción
async Ejecuta el conjunto de una función test (`it`) o setup (`beforeEach`) desde una _zona de pruebas asíncrona_ Consulta [esta discusión](guide/testing-components-scenarios#waitForAsync).
fakeAsync 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. Consulta [esta discusión](guide/testing-components-scenarios#fake-async).
tick 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_
Algún lector curioso y dedicado quizá disfrute de la lectura de esta extensa publicación en un blog: ["_Tasks, microtasks, queues and schedules_"](https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/).
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 Consulta [esta discusión](guide/testing-components-scenarios#tick).
inject Inyecta uno o más servicios desde la `TestBed` inyectora actual hacia una función de test. No puede inyectar un servicio proveído por el componente en sí. Consulta [debugElement.injector](guide/testing-components-scenarios#get-injected-services).
discardPeriodicTasks 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. 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.
flushMicrotasks Cuando un test `fakeAsync()` finaliza con micro-tareas pendientes como promesas sin resolver, el test finaliza con un mensaje de error vacío 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.
ComponentFixtureAutoDetect Un token del proveedor que inicia la [detección automática de cambios](guide/testing-components-scenarios#automatic-change-detection).
getTestBed Toma la instancia actual de la `TestBed`. Normalmente es innecesaria porque los métodos de clase estáticos de `TestBed` suelen ser suficientes. La instancia de `TestBed` muestra algunos miembros menos comunes que no están disponibles como métodos estáticos
{@a resumen-clase-testbed} ## Resumen de la clase _TestBed_ 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. La definición del módulo que pasamos a `configureTestingModule` es un subconjunto de las propiedades metadata de `@NgModule`. type TestModuleMetadata = { providers?: any[]; declarations?: any[]; imports?: any[]; schemas?: Array<SchemaMetadata | any[]>; }; {@a metadata-override-object} Cada método de sobreescribir toma un `MetadataOverride` donde `T` es el tipo de metadato apropiado para el método, es decir, el parámetro de un `@NgModule`, `@Component`, `@Directive`, o `@Pipe`. type MetadataOverride<T> = { add?: Partial<T>; remove?: Partial<T>; set?: Partial<T>; }; {@a testbed-métodos} {@a testbed-api-summary} La API `TestBed` consiste de métodos de clase estáticos que o actualizan o referencian una instancia global de `TestBed`. 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()`. Llama a los métodos `TestBed` *desde* un `beforeEach()` para asegurarte de tener un inicio en blanco antes de cada test individual. Aquí están los métodos estáticos más importantes, en orden de posible utilidad.
Métodos Descripción
configureTestingModule 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. El módulo de pruebas por defecto es configurado con declarativas básicas y algunos servicios sustitutos de Angular que cualquier tester necesitaría. 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.
compileComponents Compila el módulo de testing de forma asíncrona después de que hayas finalizado configurándolo. 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. 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.
createComponent Crea una instancia de un componente de tipo `T` basado en la configuración de la `TestBed` actual. Despuest de llamar a `compileComponent`, la configuración de `TestBed` se congela durante la especificación actual.
overrideModule Reemplaza metadatos del `NgModule` proporcionado. Recuerde que los módulos pueden importar otros módulos. El método `overrideModule` puede ir hasta el fondo del módulo testing actual para modificar alguno de estos módulos internos
overrideComponent Reemplaza metadatos para la clase componente dada, la cual puede estar anidada dentro de un módulo interno.
overrideDirective Reemplaza metadatos para la clase directiva dada, la cual puede estar anidada dentro de un módulo interno.
overridePipe Reemplaza metadatos para la clase pipe dada, la cual puede estar anidada dentro de un módulo interno.
{@a testbed-inject} inject Trae un servicio del inyector `TestBed` actual. La función `inject` normalmente es adecuada para esto, pero lanza un error si no puede proveer el servicio ¿Qué pasa si el servicio es opcional? 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): Después de llamar a `TestBed.inject`, la configuración de `TestBed` se congela durante la especificación actual.
{@a testbed-initTestEnvironment} initTestEnvironment Inicializa el medio de testing para todo el test run. Los shims de pruebas (`karma-test-shim`, `browser-test-shim`) lo llaman por ti, así que no suele haber un motivo para usarlo. Puedes llamar este método _exactamente una vez_. Si debes cambiar este valor por defecto en mitad de un test run, utiliza `resetTestEnvironment` primero. Especifica el compilador de fábrica Angular, un `PlatformRef` y un módulo por defecto de pruebas de Angular. Existen alternativas para plataformas no basadas en navegador en el formulario general siguiente: `@angular/platform-/testing/`.
resetTestEnvironment Resetea el medio de pruebas inicial, incluyendo el módulo de pruebas por defecto.
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. {@a component-fixture-api-summary} ## El _ComponentFixture_ `TestBed.createComponent` crea una instancia de un componente `T` y devuelve un `ComponentFixture` fuertemente tipificado para ese componente Las propiedades y métodos de `ComponentFixture` permiten acceso al componente, su representación DOM y algunos aspectos del medio Angular. {@a componentes-fixture-propiedades} ### Propiedades de _ComponentFixture_ Aquí están las propiedades más importantes para testers, en orden de posible utilidad.
Propiedades Descripción
componentInstance La instancia de la clase componente creada por `TestBed.createComponent`.
debugElement El `DebugElement` asociado con el elemento raíz del componente. El `DebugElement` da información sobre el componente y su elemento DOM durante el test y debug. Es una propiedad crítica para los testers. Los miembros más interesantes están cubiertos [aquí](#debug-element-details).
nativeElement El elemento DOM nativo en la raíz del componente.
changeDetectorRef El `ChangeDetectorRef` para el componente. 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.
{@a componente-fixture-métodos} ### Métodos de _ComponentFixture_ 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. Aquí están los métodos más útiles para los testers.
Métodos Descripción
detectChanges Inicia un ciclo de detección de cambios para el componente. 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. Angular no puede ver que has cambiado `personComponent.name` y no actualizará el `name` hasta que llames a `detectChanges`. Ejecuta `checkNoChanges` después para confirmar que no hay actualizaciones circulares, a no se que se llame así: `detectChanges(false)`
autoDetectChanges 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. 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. 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. El valor por defecto es `false`. Los testers que prefieren tener un control mayor sobre el comportamiento de pruebas suelen dejarlo en `false`.
checkNoChanges Corre el programa para detectar cambios y asegurarse de que no hay cambios pendientes. Lanza una excepción si los hay.
isStable Si el fixture es actualmente estable, devuelve `true`. Si hay tareas asíncronas no completadas, devuelve `false`.
whenStable Devuelve una promesa que resuelve cuando el fixture es estable. Para volver al testing después de completar actividad asíncrona o detección de cambios asíncronos, añade esta promesa. Consulta [aquí](guide/testing-components-scenarios#when-stable).
destroy Inicia la destrucción del componente
{@a debug-elementos-detalles} #### _DebugElement_ El `DebugElement` proporciona información crucial para la representación DOM de los componentes. Desde el `DebugElement` del componente test raíz, devuelto por `fixture.debugElement`, puedes llegar a todo elemento y subárbol de componentes del fixture Aquí están los miembros `DebugElement` más útiles para los testers, en orden de posible utilidad:
Miembro Descripción
nativeElement El elemento DOM correspondiente en el navegador (nulo para WebWorkers).
query Llamar a `query(predicate: Predicate)` devuelbe el primer `DebugElement` que coincida con el [predicado](#query-predicate) a cualquier profundidad en el subárbol
queryAll Llamar a `queryAll(predicate: Predicate)` devuelve todos los `DebugElements` que coincidan con el [predicado](#query-predicate) a cualquier profundidad en el subárbol
injector El inyector de dependecia del host. Por ejemplo, el inyector de la instancia del componente del elemento
componentInstance La instancia del componente del propio elemento, si tiene.
context Un objeto que provee contexto del padre para este elemento. En muchas ocasiones una instancia del componente ancestro gobierna este elemento. 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"`.
children Los hijos `DebugElement` inmediatos. Recorre el árbol descendiendo a través de los hijos.
`DebugElement` también tiene `childNodes`, una lista de objetos `DebugNode`. `DebugElement` deriva de los objetos `DebugNode` y suele haber más nodos que elementos. Los tester normalmente ignoran los nodos planos.
parent El `DebugElement` padre. Es nulo si este es el elemento raíz.
name El tag name del elemento, si es que es un elemento.
triggerEventHandler Inicia el evento por su nombre si hay un receptor correspondiente en la colección `listeners` del elemento. El segundo parámetro es el _objeto evento_ esperado por el handler. Consulta [aquí](guide/testing-components-scenarios#trigger-event-handler). Si el evento no tiene un receptor o hay algún problema, considera llamar a `nativeElement.dispatchEvent(eventObject)`.
listeners Los callbacks insertados al `@Output` del componente, sus propiedades y/o las propiedades de evento del elemento.
providerTokens Los token de búsqueda del inyector de este componente. Include el componente en sí mismo además de los tokens que el componente lista en la parte "proveedores" de sus metadatos.
source Dónde encontrar este elemento en el componente template fuente.
references Diccionario de objetos asociados a variables locales template (e.g. `#foo`), acuñado por el nombre de la variable local
{@a query-predicate} 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`. El predicado es cualquier método que tome el `DebugElement` y devuelva un valor verdadero. El siguiente ejemplo encuentra todos los `DebugElement` con una referencia a una variable local template llamada "content": La clase Angular `By` tiene tres métodos estáticos para predicados comunes: - `By.all` - devuelve todos los elementos - `By.css(selector)` - devuelve los elementos con selectores CSS coincidentes - `By.directive(directive)` - devuelve elementos que Angular ha unido a una instancia de la clase directiva.