From a2aa45d3c7402b98fd0a59a547f3ee976bc28cfb Mon Sep 17 00:00:00 2001 From: Clara Date: Wed, 28 Apr 2021 04:31:40 +0200 Subject: [PATCH] docs: traducir guide/testing-utility-apis.md (#237) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Michael Prentice Co-authored-by: Gustavo Rodríguez <47954465+gustavguez@users.noreply.github.com> Fix #231 --- aio/content/guide/testing-utility-apis.en.md | 794 +++++++++++++++++++ aio/content/guide/testing-utility-apis.md | 535 ++++++------- 2 files changed, 1034 insertions(+), 295 deletions(-) create mode 100644 aio/content/guide/testing-utility-apis.en.md 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 0000000000000..b9849c2feaf0c --- /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. + +
+ +
+ +{@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. + + + type TestModuleMetadata = { + providers?: any[]; + declarations?: any[]; + imports?: any[]; + schemas?: Array<SchemaMetadata | any[]>; + }; + + +{@a metadata-override-object} + +Each override method takes a `MetadataOverride` where `T` is the kind of metadata +appropriate to the method, that is, the parameter of an `@NgModule`, +`@Component`, `@Directive`, or `@Pipe`. + + + type MetadataOverride<T> = { + add?: Partial<T>; + remove?: Partial<T>; + set?: Partial<T>; + }; + + +{@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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ 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): + + + + After calling `TestBed.inject`, the `TestBed` configuration is frozen for the duration of the current spec. + +
+ {@a testbed-initTestEnvironment} + initTestEnvironment + + + Initialize the testing environment for the entire test run. + + The testing shims (`karma-test-shim`, `browser-test-shim`) call it for you + so there is rarely a reason for you to call it yourself. + + You may call this method _exactly once_. If you must change + this default in the middle of your test run, call `resetTestEnvironment` first. + + Specify the Angular compiler factory, a `PlatformRef`, and a default Angular testing module. + Alternatives for non-browser platforms are available in the general form + `@angular/platform-/testing/`. + +
+ resetTestEnvironment + + + Reset the initial test environment, including the default testing module. + +
+ +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` +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ 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. + +
+ +{@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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ 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. + +
+ +{@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: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Member + + Description +
+ nativeElement + + + The corresponding DOM element in the browser (null for WebWorkers). + +
+ query + + + Calling `query(predicate: Predicate)` returns the first `DebugElement` + that matches the [predicate](#query-predicate) at any depth in the subtree. + +
+ queryAll + + + Calling `queryAll(predicate: Predicate)` returns all `DebugElements` + that matches the [predicate](#query-predicate) at any depth in subtree. + +
+ injector + + + The host dependency injector. + For example, the root element's component instance injector. + +
+ componentInstance + + + The element's own component instance, if it has one. + +
+ context + + + An object that provides parent context for this element. + Often an ancestor component instance that governs this element. + + When an element is repeated within `*ngFor`, the context is an `NgForRow` whose `$implicit` + property is the value of the row instance value. + For example, the `hero` in `*ngFor="let hero of heroes"`. + +
+ children + + + The immediate `DebugElement` children. Walk the tree by descending through `children`. + +
+ + `DebugElement` also has `childNodes`, a list of `DebugNode` objects. + `DebugElement` derives from `DebugNode` objects and there are often + more nodes than elements. Testers can usually ignore plain nodes. + +
+
+ parent + + + The `DebugElement` parent. Null if this is the root element. + +
+ name + + + The element tag name, if it is an element. + +
+ triggerEventHandler + + + Triggers the event by its name if there is a corresponding listener + in the element's `listeners` collection. + The second parameter is the _event object_ expected by the handler. + See [above](guide/testing-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. + +
+ +{@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": + + + +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. + + + +
+ diff --git a/aio/content/guide/testing-utility-apis.md b/aio/content/guide/testing-utility-apis.md index 0c1b6ddd12925..1067bba8f1716 100644 --- a/aio/content/guide/testing-utility-apis.md +++ b/aio/content/guide/testing-utility-apis.md @@ -1,32 +1,34 @@ -# 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. -The [_TestBed_](#testbed-api-summary) and [_ComponentFixture_](#component-fixture-api-summary) classes are covered separately. +Las funciones de testing de Angular incluyen la `TestBed` , el `ComponentFixture` y varias funciones que controlan el medio de pruebas -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: + @@ -36,10 +38,10 @@ Here's a summary of the stand-alone functions, in order of likely utility: @@ -49,22 +51,19 @@ Here's a summary of the stand-alone functions, in order of likely utility: @@ -74,11 +73,11 @@ Here's a summary of the stand-alone functions, in order of likely utility: @@ -88,14 +87,11 @@ Here's a summary of the stand-alone functions, in order of likely utility: @@ -105,14 +101,10 @@ Here's a summary of the stand-alone functions, in order of likely utility: @@ -122,9 +114,8 @@ Here's a summary of the stand-alone functions, in order of likely utility: @@ -134,29 +125,24 @@ Here's a summary of the stand-alone functions, in order of likely utility:
- 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). +
- - 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). +
- - 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). +
- - 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. +
- - 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. +
- - 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). +
- - 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 +
-{@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. -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. +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. -The module definition passed to `configureTestingModule` -is a subset of the `@NgModule` metadata properties. +La definición del módulo que pasamos a `configureTestingModule` es un subconjunto de las propiedades metadata de `@NgModule`. type TestModuleMetadata = { @@ -169,9 +155,8 @@ is a subset of the `@NgModule` metadata properties. {@a metadata-override-object} -Each override method takes a `MetadataOverride` where `T` is the kind of metadata -appropriate to the method, that is, the parameter of an `@NgModule`, -`@Component`, `@Directive`, or `@Pipe`. +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> = { @@ -181,42 +166,40 @@ appropriate to the method, that is, the parameter of an `@NgModule`, }; -{@a testbed-methods} +{@a testbed-métodos} {@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, -which is also returned by the `getTestBed()` function. +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()`. -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. + @@ -226,14 +209,14 @@ Here are the most important static methods, in order of likely utility. @@ -243,10 +226,10 @@ Here are the most important static methods, in order of likely utility. @@ -256,10 +239,9 @@ Here are the most important static methods, in order of likely utility. @@ -269,10 +251,9 @@ Here are the most important static methods, in order of likely utility. @@ -282,10 +263,9 @@ Here are the most important static methods, in order of likely utility. @@ -295,9 +275,8 @@ Here are the most important static methods, in order of likely utility. @@ -308,22 +287,19 @@ Here are the most important static methods, in order of likely utility. @@ -334,18 +310,16 @@ Here are the most important static methods, in order of likely utility. @@ -355,39 +329,35 @@ Here are the most important static methods, in order of likely utility.
- 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. +
- - 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. +
- 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 +
- - 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. +
- - 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. +
- 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. +
- - 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): + - - 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. +
- 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-/testing/`. - +
- Reset the initial test environment, including the default testing module. - + Resetea el medio de pruebas inicial, incluyendo el módulo de pruebas por defecto. +
-A few of the `TestBed` instance methods are not covered by static `TestBed` _class_ methods. -These are rarely needed. +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} -## The _ComponentFixture_ +## El _ComponentFixture_ -The `TestBed.createComponent` -creates an instance of the component `T` -and returns a strongly typed `ComponentFixture` for that component. + `TestBed.createComponent` crea una instancia de un componente `T` y devuelve un `ComponentFixture` fuertemente tipificado para ese componente -The `ComponentFixture` properties and methods provide access to the component, -its DOM representation, and aspects of its Angular environment. +Las propiedades y métodos de `ComponentFixture` permiten acceso al componente, su representación DOM y algunos aspectos del medio Angular. -{@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. @@ -397,9 +367,9 @@ Here are the most important properties for testers, in order of likely utility. @@ -409,12 +379,13 @@ Here are the most important properties for testers, in order of likely utility. @@ -424,9 +395,9 @@ Here are the most important properties for testers, in order of likely utility. @@ -436,53 +407,48 @@ Here are the most important properties for testers, in order of likely utility.
- 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`. +
- - 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). +
- - The native DOM element at the root of the component. - + + El elemento DOM nativo en la raíz del componente. +
- - 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. +
-{@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. -Call these method to trigger Angular behavior in response to simulated user action. +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. -Here are the most useful methods for testers. +Aquí están los métodos más útiles para los testers. + @@ -492,18 +458,15 @@ Here are the most useful methods for testers. @@ -513,9 +476,10 @@ Here are the most useful methods for testers. @@ -525,10 +489,10 @@ Here are the most useful methods for testers. @@ -538,13 +502,13 @@ Here are the most useful methods for testers. @@ -554,31 +518,30 @@ Here are the most useful methods for testers.
- 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`. +
- - 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. +
- - 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`. +
- - 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). +
- - Trigger component destruction. - + + Inicia la destrucción del componente +
-{@a debug-element-details} +{@a debug-elementos-detalles} #### _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`, -you can walk (and query) the fixture's entire element and component subtrees. +Desde el `DebugElement` del componente test raíz, devuelto por `fixture.debugElement`, puedes llegar a todo elemento y subárbol de componentes del fixture -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: @@ -588,9 +551,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde @@ -600,10 +562,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde @@ -613,10 +573,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde @@ -626,10 +584,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde @@ -639,9 +595,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde @@ -651,14 +606,12 @@ Here are the most useful `DebugElement` members for testers, in approximate orde @@ -668,15 +621,14 @@ Here are the most useful `DebugElement` members for testers, in approximate orde @@ -687,8 +639,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde @@ -698,9 +650,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde @@ -710,14 +661,13 @@ Here are the most useful `DebugElement` members for testers, in approximate orde @@ -727,9 +677,9 @@ Here are the most useful `DebugElement` members for testers, in approximate orde @@ -739,10 +689,9 @@ Here are the most useful `DebugElement` members for testers, in approximate orde @@ -752,9 +701,8 @@ Here are the most useful `DebugElement` members for testers, in approximate orde @@ -764,31 +712,28 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
- 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). +
- - Calling `query(predicate: Predicate)` returns the first `DebugElement` - that matches the [predicate](#query-predicate) at any depth in the subtree. - + Llamar a `query(predicate: Predicate)` devuelbe el primer `DebugElement` que coincida con el [predicado](#query-predicate) a cualquier profundidad en el subárbol +
- - Calling `queryAll(predicate: Predicate)` returns all `DebugElements` - that matches the [predicate](#query-predicate) at any depth in subtree. - + Llamar a `queryAll(predicate: Predicate)` devuelve todos los `DebugElements` que coincidan con el [predicado](#query-predicate) a cualquier profundidad en el subárbol +
- - 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 +
- - The element's own component instance, if it has one. - + La instancia del componente del propio elemento, si tiene. +
- - 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"`. +
- - 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. +
- The `DebugElement` parent. Null if this is the root element. - + El `DebugElement` padre. Es nulo si este es el elemento raíz. +
- - The element tag name, if it is an element. - + El tag name del elemento, si es que es un elemento. +
- 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)`. +
- - 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. +
- - 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. +
- - Where to find this element in the source component template. - + Dónde encontrar este elemento en el componente template fuente. +
- - 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 +
{@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`. +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. -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": +El siguiente ejemplo encuentra todos los `DebugElement` con una referencia a una variable local template llamada "content": -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.css(selector)` - return elements with matching CSS selectors. -- `By.directive(directive)` - return elements that Angular matched to an instance of the directive class. +- `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.
-