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

docs: transalate testing-services from English to Spanish (#271)

Browse Source 
Fixes #230

Co-authored-by: José de Jesús Amaya <impepedev@gmail.com>
Co-authored-by: Pato <11162114+devpato@users.noreply.github.com>
This commit is contained in:
Jorge Yañez 2020-10-22 07:31:46 -06:00 committed by GitHub
parent dea267e5c8
commit ff7b7a9c2f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 287 additions and 89 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

199
aio/content/guide/testing-services.en.md Normal file
View File

@ -0,0 +1,199 @@
# Testing services
To check that your services are working as you intend, you can write tests specifically for them.
<div class="alert is-helpful">
For the sample app that the testing guides describe, see the <live-example name="testing" embedded-style noDownload>sample app</live-example>.
For the tests features in the testing guides, see <live-example name="testing" stackblitz="specs" noDownload>tests</live-example>.
</div>
Services are often the easiest files to unit test.
Here are some synchronous and asynchronous unit tests of the `ValueService`
written without assistance from Angular testing utilities.
<code-example path="testing/src/app/demo/demo.spec.ts" region="ValueService" header="app/demo/demo.spec.ts"></code-example>
{@a services-with-dependencies}
## Services with dependencies
Services often depend on other services that Angular injects into the constructor.
In many cases, it's easy to create and _inject_ these dependencies by hand while
calling the service's constructor.
The `MasterService` is a simple example:
<code-example path="testing/src/app/demo/demo.ts" region="MasterService" header="app/demo/demo.ts"></code-example>
`MasterService` delegates its only method, `getValue`, to the injected `ValueService`.
Here are several ways to test it.
<code-example path="testing/src/app/demo/demo.spec.ts" region="MasterService" header="app/demo/demo.spec.ts"></code-example>
The first test creates a `ValueService` with `new` and passes it to the `MasterService` constructor.
However, injecting the real service rarely works well as most dependent services are difficult to create and control.
Instead you can mock the dependency, use a dummy value, or create a
[spy](https://jasmine.github.io/2.0/introduction.html#section-Spies)
on the pertinent service method.
<div class="alert is-helpful">
Prefer spies as they are usually the easiest way to mock services.
</div>
These standard testing techniques are great for unit testing services in isolation.
However, you almost always inject services into application classes using Angular
dependency injection and you should have tests that reflect that usage pattern.
Angular testing utilities make it easy to investigate how injected services behave.
## Testing services with the _TestBed_
Your app relies on Angular [dependency injection (DI)](guide/dependency-injection)
to create services.
When a service has a dependent service, DI finds or creates that dependent service.
And if that dependent service has its own dependencies, DI finds-or-creates them as well.
As service _consumer_, you don't worry about any of this.
You don't worry about the order of constructor arguments or how they're created.
As a service _tester_, you must at least think about the first level of service dependencies
but you _can_ let Angular DI do the service creation and deal with constructor argument order
when you use the `TestBed` testing utility to provide and create services.
{@a testbed}
## Angular _TestBed_
The `TestBed` is the most important of the Angular testing utilities.
The `TestBed` creates a dynamically-constructed Angular _test_ module that emulates
an Angular [@NgModule](guide/ngmodules).
The `TestBed.configureTestingModule()` method takes a metadata object that can have most of the properties of an [@NgModule](guide/ngmodules).
To test a service, you set the `providers` metadata property with an
array of the services that you'll test or mock.
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="value-service-before-each" header="app/demo/demo.testbed.spec.ts (provide ValueService in beforeEach)"></code-example>
Then inject it inside a test by calling `TestBed.inject()` with the service class as the argument.
<div class="alert is-helpful">
**Note:** `TestBed.get()` was deprecated as of Angular version 9.
To help minimize breaking changes, Angular introduces a new function called `TestBed.inject()`, which you should use instead.
For information on the removal of `TestBed.get()`,
see its entry in the [Deprecations index](guide/deprecations#index).
</div>
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="value-service-inject-it"></code-example>
Or inside the `beforeEach()` if you prefer to inject the service as part of your setup.
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="value-service-inject-before-each"> </code-example>
When testing a service with a dependency, provide the mock in the `providers` array.
In the following example, the mock is a spy object.
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="master-service-before-each"></code-example>
The test consumes that spy in the same way it did earlier.
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="master-service-it">
</code-example>
{@a no-before-each}
## Testing without _beforeEach()_
Most test suites in this guide call `beforeEach()` to set the preconditions for each `it()` test
and rely on the `TestBed` to create classes and inject services.
There's another school of testing that never calls `beforeEach()` and prefers to create classes explicitly rather than use the `TestBed`.
Here's how you might rewrite one of the `MasterService` tests in that style.
Begin by putting re-usable, preparatory code in a _setup_ function instead of `beforeEach()`.
<code-example
path="testing/src/app/demo/demo.spec.ts"
region="no-before-each-setup"
header="app/demo/demo.spec.ts (setup)"></code-example>
The `setup()` function returns an object literal
with the variables, such as `masterService`, that a test might reference.
You don't define _semi-global_ variables (e.g., `let masterService: MasterService`)
in the body of the `describe()`.
Then each test invokes `setup()` in its first line, before continuing
with steps that manipulate the test subject and assert expectations.
<code-example
path="testing/src/app/demo/demo.spec.ts"
region="no-before-each-test"></code-example>
Notice how the test uses
[_destructuring assignment_](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment)
to extract the setup variables that it needs.
<code-example
path="testing/src/app/demo/demo.spec.ts"
region="no-before-each-setup-call">
</code-example>
Many developers feel this approach is cleaner and more explicit than the
traditional `beforeEach()` style.
Although this testing guide follows the traditional style and
the default [CLI schematics](https://github.com/angular/angular-cli)
generate test files with `beforeEach()` and `TestBed`,
feel free to adopt _this alternative approach_ in your own projects.
## Testing HTTP services
Data services that make HTTP calls to remote servers typically inject and delegate
to the Angular [`HttpClient`](guide/http) service for XHR calls.
You can test a data service with an injected `HttpClient` spy as you would
test any service with a dependency.
<code-example
path="testing/src/app/model/hero.service.spec.ts"
region="test-with-spies"
header="app/model/hero.service.spec.ts (tests with spies)">
</code-example>
<div class="alert is-important">
The `HeroService` methods return `Observables`. You must
_subscribe_ to an observable to (a) cause it to execute and (b)
assert that the method succeeds or fails.
The `subscribe()` method takes a success (`next`) and fail (`error`) callback.
Make sure you provide _both_ callbacks so that you capture errors.
Neglecting to do so produces an asynchronous uncaught observable error that
the test runner will likely attribute to a completely different test.
</div>
## _HttpClientTestingModule_
Extended interactions between a data service and the `HttpClient` can be complex
and difficult to mock with spies.
The `HttpClientTestingModule` can make these testing scenarios more manageable.
While the _code sample_ accompanying this guide demonstrates `HttpClientTestingModule`,
this page defers to the [Http guide](guide/http#testing-http-requests),
which covers testing with the `HttpClientTestingModule` in detail.

177
aio/content/guide/testing-services.md
View File

@ -1,172 +1,172 @@
# Testing services # Probando servicios
To check that your services are working as you intend, you can write tests specifically for them. Para comprobar que tus servicios funcionan como deseas, puedes escribir pruebas específicamente para ellos.
<div class="alert is-helpful"> <div class="alert is-helpful">
For the sample app that the testing guides describe, see the <live-example name="testing" embedded-style noDownload>sample app</live-example>. Para la aplicación de muestra que describe las guías de prueba, consulta la <live-example name="testing" embedded-style noDownload>aplicación de muestra</live-example>.
For the tests features in the testing guides, see <live-example name="testing" stackblitz="specs" noDownload>tests</live-example>. Para las funcionalidades de las pruebas en las guías de prueba, consulta las <live-example name="testing" stackblitz="specs" noDownload>pruebas</live-example>.
</div> </div>
Services are often the easiest files to unit test. Los servicios suelen ser los archivos en los que es mas fácil realizar pruebas unitarias.
Here are some synchronous and asynchronous unit tests of the `ValueService` Estas son algunas pruebas unitarias sincrónicas y asincrónicas del `ValueService`
written without assistance from Angular testing utilities. escritas sin ayuda de las utilidades de prueba Angular.
<code-example path="testing/src/app/demo/demo.spec.ts" region="ValueService" header="app/demo/demo.spec.ts"></code-example> <code-example path="testing/src/app/demo/demo.spec.ts" region="ValueService" header="app/demo/demo.spec.ts"></code-example>
{@a services-with-dependencies} {@a services-with-dependencies}
## Services with dependencies ## Servicios con dependencias
Services often depend on other services that Angular injects into the constructor. Los servicios a menudo dependen de otros servicios que Angular inyecta en el constructor.
In many cases, it's easy to create and _inject_ these dependencies by hand while En muchos casos, es fácil crear e _inyectar_ estas dependencias a mano mientras
calling the service's constructor. se llama al constructor del servicio.
The `MasterService` is a simple example: El `MasterService` es un ejemplo simple:
<code-example path="testing/src/app/demo/demo.ts" region="MasterService" header="app/demo/demo.ts"></code-example> <code-example path="testing/src/app/demo/demo.ts" region="MasterService" header="app/demo/demo.ts"></code-example>
`MasterService` delegates its only method, `getValue`, to the injected `ValueService`. `MasterService` delega su único método, `getValue`, al `ValueService` inyectado.
Here are several ways to test it. Aquí hay varias formas de probarlo.
<code-example path="testing/src/app/demo/demo.spec.ts" region="MasterService" header="app/demo/demo.spec.ts"></code-example> <code-example path="testing/src/app/demo/demo.spec.ts" region="MasterService" header="app/demo/demo.spec.ts"></code-example>
The first test creates a `ValueService` with `new` and passes it to the `MasterService` constructor. La primera prueba crea un `ValueService` con `new` y lo pasa al constructor de `MasterService`.
However, injecting the real service rarely works well as most dependent services are difficult to create and control. Sin embargo, inyectar el servicio real rara vez funciona bien, ya que la mayoría de los servicios dependientes son difíciles de crear y controlar.
Instead you can mock the dependency, use a dummy value, or create a En su lugar, puedes hacer un mock de la dependencia, usar un valor ficticio o crear un
[spy](https://jasmine.github.io/2.0/introduction.html#section-Spies) [espía](https://jasmine.github.io/2.0/introduction.html#section-Spies)
on the pertinent service method. sobre el método del servicio pertinente.
<div class="alert is-helpful"> <div class="alert is-helpful">
Prefer spies as they are usually the easiest way to mock services. Utiliza espías, ya que suelen ser la forma más fácil de hacer mocks a los servicios.
</div> </div>
These standard testing techniques are great for unit testing services in isolation. Estas técnicas de prueba estándar son excelentes para hacer pruebas unitarias de servicios de forma aislada.
However, you almost always inject services into application classes using Angular Sin embargo, casi siempre inyecta servicios en clases de aplicación usando
dependency injection and you should have tests that reflect that usage pattern. la inyección de dependencias de Angular y debe tener pruebas que reflejen ese patrón de uso.
Angular testing utilities make it easy to investigate how injected services behave. Las utilidades de pruebas de Angular facilitan la investigación de cómo se comportan los servicios inyectados.
## Testing services with the _TestBed_ ## Probando los servicios con _TestBed_
Your app relies on Angular [dependency injection (DI)](guide/dependency-injection) Tu aplicación se basa en la [inyección de dependencias (ID)](guide/dependency-injection) de Angular
to create services. para crear servicios.
When a service has a dependent service, DI finds or creates that dependent service. Cuando un servicio tiene un servicio dependiente, la inyección de dependencia busca o crea ese servicio dependiente.
And if that dependent service has its own dependencies, DI finds-or-creates them as well. Y si ese servicio dependiente tiene sus propias dependencias, la inyección de dependencia también las encuentra o crea.
As service _consumer_, you don't worry about any of this. Como _consumidor_ de servicios, no te preocupas por nada de esto.
You don't worry about the order of constructor arguments or how they're created. No te preocupes por el orden de los argumentos del constructor o cómo se crean.
As a service _tester_, you must at least think about the first level of service dependencies Como _probador_ de servicios, debes pensar al menos en el primer nivel de dependencias del servicio
but you _can_ let Angular DI do the service creation and deal with constructor argument order pero _puedes_ dejar que la inyección de dependencia de Angular haga la creación del servicio y se ocupe del orden de los argumentos del constructor
when you use the `TestBed` testing utility to provide and create services. cuando uses la utilidad de prueba `TestBed` para proporcionar y crear servicios.
{@a testbed} {@a testbed}
## Angular _TestBed_ ## Angular _TestBed_
The `TestBed` is the most important of the Angular testing utilities. El `TestBed` es la más importante de las utilidades de prueba de Angular.
The `TestBed` creates a dynamically-constructed Angular _test_ module that emulates El `TestBed` crea un modulo Angular _test_ construido dinámicamente que emula
an Angular [@NgModule](guide/ngmodules). un [@NgModule](guide/ngmodules) de Angular.
The `TestBed.configureTestingModule()` method takes a metadata object that can have most of the properties of an [@NgModule](guide/ngmodules). El método `TestBed.configureTestingModule()` toma un objeto de metadatos que puede tener la mayoría de las propiedades de un [@NgModule](guide/ngmodules).
To test a service, you set the `providers` metadata property with an Para probar un servicio, estableces la propiedad de metadatos de `providers` con un
array of the services that you'll test or mock. array de los servicios que probarás o simularás.
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="value-service-before-each" header="app/demo/demo.testbed.spec.ts (provide ValueService in beforeEach)"></code-example> <code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="value-service-before-each" header="app/demo/demo.testbed.spec.ts (provide ValueService in beforeEach)"></code-example>
Then inject it inside a test by calling `TestBed.inject()` with the service class as the argument. Luego inyéctalo dentro de una prueba llamando `TestBed.inject()` con la clase del servicio como argumento.
<div class="alert is-helpful"> <div class="alert is-helpful">
**Note:** `TestBed.get()` was deprecated as of Angular version 9. **Nota:** `TestBed.get()` quedó obsoleto a partir de la versión 9 de Angular.
To help minimize breaking changes, Angular introduces a new function called `TestBed.inject()`, which you should use instead. Para ayudar a minimizar los cambios importantes, Angular presenta una nueva función llamada `TestBed.inject()`, que deberas usar en su lugar.
For information on the removal of `TestBed.get()`, Para obtener información sobre la eliminación de `TestBed.get()`,
see its entry in the [Deprecations index](guide/deprecations#index). consulta su entrada en el [Índice de bajas](guide/deprecations#index).
</div> </div>
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="value-service-inject-it"></code-example> <code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="value-service-inject-it"></code-example>
Or inside the `beforeEach()` if you prefer to inject the service as part of your setup. O dentro del `beforeEach()` si prefieres inyectar el servicio como parte de tu configuración.
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="value-service-inject-before-each"> </code-example> <code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="value-service-inject-before-each"> </code-example>
When testing a service with a dependency, provide the mock in the `providers` array. Al probar un servicio con una dependencia, proporcione un mock en el array de `providers`.
In the following example, the mock is a spy object. En el siguiente ejemplo, el mock es un objeto espía.
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="master-service-before-each"></code-example> <code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="master-service-before-each"></code-example>
The test consumes that spy in the same way it did earlier. La prueba consume ese espía de la misma manera que lo hizo antes.
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="master-service-it"> <code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="master-service-it">
</code-example> </code-example>
{@a no-before-each} {@a no-before-each}
## Testing without _beforeEach()_ ## Pruebas sin _beforeEach()_
Most test suites in this guide call `beforeEach()` to set the preconditions for each `it()` test La mayoría de los conjuntos de pruebas en esta guía llaman a `beforeEach()` para establecer las condiciones previas para cada prueba `it()`
and rely on the `TestBed` to create classes and inject services. y confían en `TestBed` para crear clases e inyectar servicios.
There's another school of testing that never calls `beforeEach()` and prefers to create classes explicitly rather than use the `TestBed`. Hay otra escuela de pruebas que nunca llama a `beforeEach()` y prefiere crear clases explícitamente en lugar de usar el `TestBed`.
Here's how you might rewrite one of the `MasterService` tests in that style. Así es como podrías reescribir una de las pruebas del `MasterService` en ese estilo.
Begin by putting re-usable, preparatory code in a _setup_ function instead of `beforeEach()`. Empieza poniendo código preparatorio reutilizable en una función _setup_ en lugar de `beforeEach()`.
<code-example <code-example
path="testing/src/app/demo/demo.spec.ts" path="testing/src/app/demo/demo.spec.ts"
region="no-before-each-setup" region="no-before-each-setup"
header="app/demo/demo.spec.ts (setup)"></code-example> header="app/demo/demo.spec.ts (setup)"></code-example>
The `setup()` function returns an object literal La función `setup()` devuelve un objeto literal
with the variables, such as `masterService`, that a test might reference. con las variables, como `masterService`, a las que una prueba podría hacer referencia.
You don't define _semi-global_ variables (e.g., `let masterService: MasterService`) No defines variables _semi-globales_ (por ejemplo, `let masterService: MasterService`)
in the body of the `describe()`. en el cuerpo de `describe()`.
Then each test invokes `setup()` in its first line, before continuing Luego, cada prueba invoca `setup()` en su primera línea, antes de continuar
with steps that manipulate the test subject and assert expectations. con pasos que manipulan al sujeto de prueba y afirman expectativas.
<code-example <code-example
path="testing/src/app/demo/demo.spec.ts" path="testing/src/app/demo/demo.spec.ts"
region="no-before-each-test"></code-example> region="no-before-each-test"></code-example>
Notice how the test uses Observe cómo la prueba usa
[_destructuring assignment_](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) [_desestructuración de asignación_](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment)
to extract the setup variables that it needs. para extraer las variables de configuración que necesita.
<code-example <code-example
path="testing/src/app/demo/demo.spec.ts" path="testing/src/app/demo/demo.spec.ts"
region="no-before-each-setup-call"> region="no-before-each-setup-call">
</code-example> </code-example>
Many developers feel this approach is cleaner and more explicit than the Muchos desarrolladores sienten que este enfoque es más limpio y explícito que el
traditional `beforeEach()` style. que el estilo tradicional `beforeEach()`.
Although this testing guide follows the traditional style and Aunque esta guía de prueba sigue el estilo tradicional y
the default [CLI schematics](https://github.com/angular/angular-cli) los [esquemas CLI](https://github.com/angular/angular-cli) predeterminados
generate test files with `beforeEach()` and `TestBed`, generan archivos de prueba con `beforeEach()` y `TestBed`,
feel free to adopt _this alternative approach_ in your own projects. no dudes en adoptar _este enfoque alternativo_ en tus propios proyectos.
## Testing HTTP services ## Pruebas de servicios HTTP
Data services that make HTTP calls to remote servers typically inject and delegate Los servicios de datos que realizan llamadas HTTP a servidores remotos normalmente inyectan y delegan
to the Angular [`HttpClient`](guide/http) service for XHR calls. al servicio Angular [`HttpClient`](guide/http) para llamadas XHR.
You can test a data service with an injected `HttpClient` spy as you would Puedes probar un servicio de datos con un espía `HttpClient` inyectado como lo harías
test any service with a dependency. con cualquier servicio con una dependencia.
<code-example <code-example
path="testing/src/app/model/hero.service.spec.ts" path="testing/src/app/model/hero.service.spec.ts"
region="test-with-spies" region="test-with-spies"
@ -175,25 +175,24 @@ test any service with a dependency.
<div class="alert is-important"> <div class="alert is-important">
The `HeroService` methods return `Observables`. You must Los métodos del `HeroService` devuelven `Observables`. Debes
_subscribe_ to an observable to (a) cause it to execute and (b) _subscribirte_ a un observable para (a) hacer que se ejecute y (b)
assert that the method succeeds or fails. afirmar que el método funciona o no.
The `subscribe()` method takes a success (`next`) and fail (`error`) callback. El método `subscribe()` toma una callback de éxito (`next`) y una de falla (`error`).
Make sure you provide _both_ callbacks so that you capture errors. Asegurate de proporcionar _ambas_ callback para capturar errores.
Neglecting to do so produces an asynchronous uncaught observable error that Si no lo haces, se produce un error observable asincrónico no detectado que el
the test runner will likely attribute to a completely different test. test runner probablemente atribuirá a una prueba completamente diferente.
</div> </div>
## _HttpClientTestingModule_ ## _HttpClientTestingModule_
Extended interactions between a data service and the `HttpClient` can be complex Las interacciones extendidas entre un servicio de datos y el `HttpClient` pueden ser complejas
and difficult to mock with spies. y difícil de crear un mock con los espías.
The `HttpClientTestingModule` can make these testing scenarios more manageable. El `HttpClientTestingModule` puede hacer que estos escenarios de prueba sean más manejables.
While the _code sample_ accompanying this guide demonstrates `HttpClientTestingModule`,
this page defers to the [Http guide](guide/http#testing-http-requests),
which covers testing with the `HttpClientTestingModule` in detail.
Si bien el _ejemplo de código_ que acompaña a esta guía muestra `HttpClientTestingModule`,
esta página se remite a la [guía Http](guide/http#testing-http-requests),
que cubre las pruebas con el `HttpClientTestingModule` en detalle.