diff --git a/aio/content/guide/testing-utility-apis.en.md b/aio/content/guide/testing-utility-apis.en.md new file mode 100644 index 0000000000..b9849c2fea --- /dev/null +++ b/aio/content/guide/testing-utility-apis.en.md @@ -0,0 +1,794 @@ +# Testing Utility APIs + +This page describes the most useful Angular testing features. + +The Angular testing utilities include the `TestBed`, the `ComponentFixture`, and a handful of functions that control the test environment. +The [_TestBed_](#testbed-api-summary) and [_ComponentFixture_](#component-fixture-api-summary) classes are covered separately. + +Here's a summary of the stand-alone functions, in order of likely utility: + +
+ Function + | ++ Description + | +
---|---|
+ async
+ |
+
+ + + Runs the body of a test (`it`) or setup (`beforeEach`) function within a special _async test zone_. + See [discussion above](guide/testing-components-scenarios#waitForAsync). + + | +
+ fakeAsync
+ |
+
+ + + Runs the body of a test (`it`) within a special _fakeAsync test zone_, enabling + a linear control flow coding style. See [discussion above](guide/testing-components-scenarios#fake-async). + + | +
+ tick
+ |
+
+
+
+ Simulates the passage of time and the completion of pending asynchronous activities
+ by flushing both _timer_ and _micro-task_ queues within the _fakeAsync test zone_.
+
+
+
+ The curious, dedicated reader might enjoy this lengthy blog post,
+ ["_Tasks, microtasks, queues and schedules_"](https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/).
+
+
+
+ Accepts an optional argument that moves the virtual clock forward
+ by the specified number of milliseconds,
+ clearing asynchronous activities scheduled within that timeframe.
+ See [discussion above](guide/testing-components-scenarios#tick).
+
+ |
+
+ inject
+ |
+
+ + + Injects one or more services from the current `TestBed` injector into a test function. + It cannot inject a service provided by the component itself. + See discussion of the [debugElement.injector](guide/testing-components-scenarios#get-injected-services). + + | +
+ discardPeriodicTasks
+ |
+
+ + + When a `fakeAsync()` test ends with pending timer event _tasks_ (queued `setTimeOut` and `setInterval` callbacks), + the test fails with a clear error message. + + In general, a test should end with no queued tasks. + When pending timer tasks are expected, call `discardPeriodicTasks` to flush the _task_ queue + and avoid the error. + + | +
+ flushMicrotasks
+ |
+
+ + + When a `fakeAsync()` test ends with pending _micro-tasks_ such as unresolved promises, + the test fails with a clear error message. + + In general, a test should wait for micro-tasks to finish. + When pending microtasks are expected, call `flushMicrotasks` to flush the _micro-task_ queue + and avoid the error. + + | +
+ ComponentFixtureAutoDetect
+ |
+
+ + + A provider token for a service that turns on [automatic change detection](guide/testing-components-scenarios#automatic-change-detection). + + | +
+ getTestBed
+ |
+
+ + + Gets the current instance of the `TestBed`. + Usually unnecessary because the static class methods of the `TestBed` class are typically sufficient. + The `TestBed` instance exposes a few rarely used members that are not available as + static methods. + + | +
+ Methods + | ++ Description + | +
---|---|
+ configureTestingModule
+ |
+
+ + + The testing shims (`karma-test-shim`, `browser-test-shim`) + establish the [initial test environment](guide/testing) and a default testing module. + The default testing module is configured with basic declaratives and some Angular service substitutes that every tester needs. + + Call `configureTestingModule` to refine the testing module configuration for a particular set of tests + by adding and removing imports, declarations (of components, directives, and pipes), and providers. + + | +
+ compileComponents
+ |
+
+ + + Compile the testing module asynchronously after you've finished configuring it. + You **must** call this method if _any_ of the testing module components have a `templateUrl` + or `styleUrls` because fetching component template and style files is necessarily asynchronous. + See [above](guide/testing-components-scenarios#compile-components). + + After calling `compileComponents`, the `TestBed` configuration is frozen for the duration of the current spec. + + | +
+ createComponent
+ |
+
+ + + Create an instance of a component of type `T` based on the current `TestBed` configuration. + After calling `compileComponent`, the `TestBed` configuration is frozen for the duration of the current spec. + + | +
+ overrideModule
+ |
+ + + Replace metadata for the given `NgModule`. Recall that modules can import other modules. + The `overrideModule` method can reach deeply into the current testing module to + modify one of these inner modules. + + | +
+ overrideComponent
+ |
+
+ + + Replace metadata for the given component class, which could be nested deeply + within an inner module. + + | +
+ overrideDirective
+ |
+
+ + + Replace metadata for the given directive class, which could be nested deeply + within an inner module. + + | +
+ overridePipe
+ |
+ + + Replace metadata for the given pipe class, which could be nested deeply + within an inner module. + + | +
+ {@a testbed-inject}
+ inject
+ |
+
+
+
+ Retrieve a service from the current `TestBed` injector.
+
+ The `inject` function is often adequate for this purpose.
+ But `inject` throws an error if it can't provide the service.
+
+ What if the service is optional?
+
+ The `TestBed.inject()` method takes an optional second parameter,
+ the object to return if Angular can't find the provider
+ (`null` in this example):
+
+ |
+
+ {@a testbed-initTestEnvironment}
+ initTestEnvironment
+ |
+
+
+ Initialize the testing environment for the entire test run.
+
+ The testing shims (`karma-test-shim`, `browser-test-shim`) call it for you
+ so there is rarely a reason for you to call it yourself.
+
+ You may call this method _exactly once_. If you must change
+ this default in the middle of your test run, call `resetTestEnvironment` first.
+
+ Specify the Angular compiler factory, a `PlatformRef`, and a default Angular testing module.
+ Alternatives for non-browser platforms are available in the general form
+ `@angular/platform- |
+
+ 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](#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-components-scenarios#when-stable). + + | +
+ destroy
+ |
+
+ + + Trigger component destruction. + + | +
+ Member + | ++ Description + | +
---|---|
+ nativeElement
+ |
+
+ + + The corresponding DOM element in the browser (null for WebWorkers). + + | +
+ query
+ |
+
+
+
+ Calling `query(predicate: Predicate |
+
+ queryAll
+ |
+
+
+
+ Calling `queryAll(predicate: Predicate |
+
+ injector
+ |
+
+ + + The host dependency injector. + For example, the root element's component instance injector. + + | +
+ componentInstance
+ |
+
+ + + The element's own component instance, if it has one. + + | +
+ context
+ |
+
+ + + An object that provides parent context for this element. + Often an ancestor component instance that governs this element. + + When an element is repeated within `*ngFor`, the context is an `NgForRow` whose `$implicit` + property is the value of the row instance value. + For example, the `hero` in `*ngFor="let hero of heroes"`. + + | +
+ children
+ |
+
+
+
+ The immediate `DebugElement` children. Walk the tree by descending through `children`.
+
+
+
+ `DebugElement` also has `childNodes`, a list of `DebugNode` objects.
+ `DebugElement` derives from `DebugNode` objects and there are often
+ more nodes than elements. Testers can usually ignore plain nodes.
+
+
+ |
+
+ parent
+ |
+ + + The `DebugElement` parent. Null if this is the root element. + + | +
+ name
+ |
+
+ + + The element tag name, if it is an element. + + | +
+ triggerEventHandler
+ |
+ + + Triggers the event by its name if there is a corresponding listener + in the element's `listeners` collection. + The second parameter is the _event object_ expected by the handler. + See [above](guide/testing-components-scenarios#trigger-event-handler). + + If the event lacks a listener or there's some other problem, + consider calling `nativeElement.dispatchEvent(eventObject)`. + + | +
+ listeners
+ |
+
+ + + The callbacks attached to the component's `@Output` properties and/or the element's event properties. + + | +
+ providerTokens
+ |
+
+ + + This component's injector lookup tokens. + Includes the component itself plus the tokens that the component lists in its `providers` metadata. + + | +
+ source
+ |
+
+ + + Where to find this element in the source component template. + + | +
+ references
+ |
+
+ + + Dictionary of objects associated with template local variables (e.g. `#foo`), + keyed by the local variable name. + + | +
- Function + Función | - Description + Descripción |
---|---|
async
|
- - Runs the body of a test (`it`) or setup (`beforeEach`) function within a special _async test zone_. - See [discussion above](guide/testing-components-scenarios#waitForAsync). - + + 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). + | - - 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). - + + 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). + | @@ -49,22 +51,19 @@ Here's a summary of the stand-alone functions, in order of likely utility:
-
- 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_.
-
+
+ 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_
+
-
- The curious, dedicated reader might enjoy this lengthy blog post,
+ 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/).
-
+
-
- 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).
-
+
+ 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).
+
|
@@ -74,11 +73,11 @@ Here's a summary of the stand-alone functions, in order of likely utility:
- - 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). - + + 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). + | @@ -88,14 +87,11 @@ Here's a summary of the stand-alone functions, in order of likely utility:- - 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. - + + 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. + | @@ -105,14 +101,10 @@ Here's a summary of the stand-alone functions, in order of likely utility:- - 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. - + 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. + | @@ -122,9 +114,8 @@ Here's a summary of the stand-alone functions, in order of likely utility:- - A provider token for a service that turns on [automatic change detection](guide/testing-components-scenarios#automatic-change-detection). - + Un token del proveedor que inicia la [detección automática de cambios](guide/testing-components-scenarios#automatic-change-detection). + | @@ -134,29 +125,24 @@ Here's a summary of the stand-alone functions, in order of likely utility:- - 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. - + + 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 + |
- Methods + Métodos | - Description + Descripción |
---|---|
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. - + + 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. + | - - 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. - + + 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. + | @@ -243,10 +226,10 @@ Here are the most important static methods, in order of likely utility.- - 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. - + + 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. + | @@ -256,10 +239,9 @@ Here are the most important static methods, in order of likely utility.- 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. - + 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 + | @@ -269,10 +251,9 @@ Here are the most important static methods, in order of likely utility.- - Replace metadata for the given component class, which could be nested deeply - within an inner module. - + + Reemplaza metadatos para la clase componente dada, la cual puede estar anidada dentro de un módulo interno. + | @@ -282,10 +263,9 @@ Here are the most important static methods, in order of likely utility.- - Replace metadata for the given directive class, which could be nested deeply - within an inner module. - + + Reemplaza metadatos para la clase directiva dada, la cual puede estar anidada dentro de un módulo interno. + | @@ -295,9 +275,8 @@ Here are the most important static methods, in order of likely utility.- Replace metadata for the given pipe class, which could be nested deeply - within an inner module. - + Reemplaza metadatos para la clase pipe dada, la cual puede estar anidada dentro de un módulo interno. + | @@ -308,22 +287,19 @@ Here are the most important static methods, in order of likely utility.
-
- 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):
-
+
+ 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):
+
|
@@ -334,18 +310,16 @@ Here are the most important static methods, in order of likely utility.
- 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
+ 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- |
@@ -355,39 +329,35 @@ Here are the most important static methods, in order of likely utility.
- Reset the initial test environment, including the default testing module. - + Resetea el medio de pruebas inicial, incluyendo el módulo de pruebas por defecto. + |
- Properties + Propiedades | - Description + Descripción | - - The instance of the component class created by `TestBed.createComponent`. - + + La instancia de la clase componente creada por `TestBed.createComponent`. + | @@ -409,12 +379,13 @@ Here are the most important properties for testers, in order of likely utility.- - 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). - + + 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). + | @@ -424,9 +395,9 @@ Here are the most important properties for testers, in order of likely utility.- - The native DOM element at the root of the component. - + + El elemento DOM nativo en la raíz del componente. + | @@ -436,53 +407,48 @@ Here are the most important properties for testers, in order of likely utility.- - 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. - + + 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. + |
---|
- Methods + Métodos | - Description + Descripción |
---|---|
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)`; - + + 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)` + | - + + 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. - - 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`. - + + 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`. + | @@ -513,9 +476,10 @@ Here are the most useful methods for testers.- - Do a change detection run to make sure there are no pending changes. - Throws an exceptions if there are. + + Corre el programa para detectar cambios y asegurarse de que no hay cambios pendientes. + Lanza una excepción si los hay. + | @@ -525,10 +489,10 @@ Here are the most useful methods for testers.- - If the fixture is currently _stable_, returns `true`. - If there are async tasks that have not completed, returns `false`. - + + Si el fixture es actualmente estable, devuelve `true`. + Si hay tareas asíncronas no completadas, devuelve `false`. + | @@ -538,13 +502,13 @@ Here are the most useful methods for testers.- - 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). - + + 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). + | @@ -554,31 +518,30 @@ Here are the most useful methods for testers.- - Trigger component destruction. - + + Inicia la destrucción del componente + |
- Member + Miembro | - Description + Descripción | - - The corresponding DOM element in the browser (null for WebWorkers). - + El elemento DOM correspondiente en el navegador (nulo para WebWorkers). + | @@ -600,10 +562,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
-
- Calling `query(predicate: Predicate |
@@ -613,10 +573,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
-
- Calling `queryAll(predicate: Predicate |
@@ -626,10 +584,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
- - The host dependency injector. - For example, the root element's component instance injector. - + El inyector de dependecia del host. Por ejemplo, el inyector de la instancia del componente del elemento + | @@ -639,9 +595,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde- - The element's own component instance, if it has one. - + La instancia del componente del propio elemento, si tiene. + | @@ -651,14 +606,12 @@ Here are the most useful `DebugElement` members for testers, in approximate orde- - 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"`. - + + 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"`. + | @@ -668,15 +621,14 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
-
- 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.
+
-
- `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.
-
+
+ `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.
+
|
@@ -687,8 +639,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
- The `DebugElement` parent. Null if this is the root element. - + El `DebugElement` padre. Es nulo si este es el elemento raíz. + | @@ -698,9 +650,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde- - The element tag name, if it is an element. - + El tag name del elemento, si es que es un elemento. + | @@ -710,14 +661,13 @@ Here are the most useful `DebugElement` members for testers, in approximate orde- 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)`. - + 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)`. + | @@ -727,9 +677,9 @@ Here are the most useful `DebugElement` members for testers, in approximate orde- - 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. + | @@ -739,10 +689,9 @@ Here are the most useful `DebugElement` members for testers, in approximate orde- - This component's injector lookup tokens. - Includes the component itself plus the tokens that the component lists in its `providers` metadata. - + 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. + | @@ -752,9 +701,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde- - Where to find this element in the source component template. - + Dónde encontrar este elemento en el componente template fuente. + | @@ -764,31 +712,28 @@ Here are the most useful `DebugElement` members for testers, in approximate orde- - Dictionary of objects associated with template local variables (e.g. `#foo`), - keyed by the local variable name. - + Diccionario de objetos asociados a variables locales template (e.g. `#foo`), acuñado por el nombre de la variable local + |
---|