Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 15 additions & 15 deletions adev-es/src/app/routing/sub-navigation-data.ts
Original file line number Diff line number Diff line change
Expand Up @@ -510,51 +510,51 @@ const DOCS_SUB_NAVIGATION_DATA: NavigationItem[] = [
],
},
{
label: 'Testing',
label: 'Pruebas',
children: [
{
label: 'Overview',
label: 'Visión general',
path: 'guide/testing',
contentPath: 'guide/testing/overview',
},
{
label: 'Code coverage',
label: 'Cobertura de código',
path: 'guide/testing/code-coverage',
contentPath: 'guide/testing/code-coverage',
},
{
label: 'Testing services',
label: 'Pruebas de servicios',
path: 'guide/testing/services',
contentPath: 'guide/testing/services',
},
{
label: 'Basics of testing components',
label: 'Fundamentos de pruebas de componentes',
path: 'guide/testing/components-basics',
contentPath: 'guide/testing/components-basics',
},
{
label: 'Component testing scenarios',
label: 'Escenarios de pruebas de componentes',
path: 'guide/testing/components-scenarios',
contentPath: 'guide/testing/components-scenarios',
},
{
label: 'Testing attribute directives',
label: 'Pruebas de directivas de atributo',
path: 'guide/testing/attribute-directives',
contentPath: 'guide/testing/attribute-directives',
},
{
label: 'Testing pipes',
label: 'Pruebas de pipes',
path: 'guide/testing/pipes',
contentPath: 'guide/testing/pipes',
},
{
label: 'Testing routing and navigation',
label: 'Pruebas de enrutamiento y navegación',
path: 'guide/routing/testing',
contentPath: 'guide/routing/testing',
status: 'new',
},
{
label: 'Debugging tests',
label: 'Depuración de pruebas',
path: 'guide/testing/debugging',
contentPath: 'guide/testing/debugging',
},
Expand All @@ -564,27 +564,27 @@ const DOCS_SUB_NAVIGATION_DATA: NavigationItem[] = [
contentPath: 'guide/testing/utility-apis',
},
{
label: 'Experimental unit testing integration',
label: 'Integración experimental de pruebas unitarias',
path: 'guide/testing/unit-tests',
contentPath: 'guide/testing/experimental-unit-test',
},
{
label: 'Component harnesses overview',
label: 'Visión general de component harnesses',
path: 'guide/testing/component-harnesses-overview',
contentPath: 'guide/testing/component-harnesses-overview',
},
{
label: 'Using component harnesses in tests',
label: 'Usando component harnesses en pruebas',
path: 'guide/testing/using-component-harnesses',
contentPath: 'guide/testing/using-component-harnesses',
},
{
label: 'Creating harnesses for your components',
label: 'Creando harnesses para tus componentes',
path: 'guide/testing/creating-component-harnesses',
contentPath: 'guide/testing/creating-component-harnesses',
},
{
label: 'Adding harness support for additional testing environments',
label: 'Agregar soporte de harness para entornos de pruebas adicionales',
path: 'guide/testing/component-harnesses-testing-environments',
contentPath: 'guide/testing/component-harnesses-testing-environments',
},
Expand Down
53 changes: 53 additions & 0 deletions adev-es/src/content/guide/testing/attribute-directives.en.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@

# Testing Attribute Directives

An *attribute directive* modifies the behavior of an element, component or another directive.
Its name reflects the way the directive is applied: as an attribute on a host element.

## Testing the `HighlightDirective`

The sample application's `HighlightDirective` sets the background color of an element based on either a data bound color or a default color \(lightgray\).
It also sets a custom property of the element \(`customProperty`\) to `true` for no reason other than to show that it can.

<docs-code header="app/shared/highlight.directive.ts" path="adev/src/content/examples/testing/src/app/shared/highlight.directive.ts"/>

It's used throughout the application, perhaps most simply in the `AboutComponent`:

<docs-code header="app/about/about.component.ts" path="adev/src/content/examples/testing/src/app/about/about.component.ts"/>

Testing the specific use of the `HighlightDirective` within the `AboutComponent` requires only the techniques explored in the ["Nested component tests"](guide/testing/components-scenarios#nested-component-tests) section of [Component testing scenarios](guide/testing/components-scenarios).

<docs-code header="app/about/about.component.spec.ts" path="adev/src/content/examples/testing/src/app/about/about.component.spec.ts" visibleRegion="tests"/>

However, testing a single use case is unlikely to explore the full range of a directive's capabilities.
Finding and testing all components that use the directive is tedious, brittle, and almost as unlikely to afford full coverage.

*Class-only tests* might be helpful, but attribute directives like this one tend to manipulate the DOM.
Isolated unit tests don't touch the DOM and, therefore, do not inspire confidence in the directive's efficacy.

A better solution is to create an artificial test component that demonstrates all ways to apply the directive.

<docs-code header="app/shared/highlight.directive.spec.ts (TestComponent)" path="adev/src/content/examples/testing/src/app/shared/highlight.directive.spec.ts" visibleRegion="test-component"/>

<img alt="HighlightDirective spec in action" src="assets/images/guide/testing/highlight-directive-spec.png">

HELPFUL: The `<input>` case binds the `HighlightDirective` to the name of a color value in the input box.
The initial value is the word "cyan" which should be the background color of the input box.

Here are some tests of this component:

<docs-code header="app/shared/highlight.directive.spec.ts (selected tests)" path="adev/src/content/examples/testing/src/app/shared/highlight.directive.spec.ts" visibleRegion="selected-tests"/>

A few techniques are noteworthy:

* The `By.directive` predicate is a great way to get the elements that have this directive *when their element types are unknown*
* The [`:not` pseudo-class](https://developer.mozilla.org/docs/Web/CSS/:not) in `By.css('h2:not([highlight])')` helps find `<h2>` elements that *do not* have the directive.
`By.css('*:not([highlight])')` finds *any* element that does not have the directive.

* `DebugElement.styles` affords access to element styles even in the absence of a real browser, thanks to the `DebugElement` abstraction.
But feel free to exploit the `nativeElement` when that seems easier or more clear than the abstraction.

* Angular adds a directive to the injector of the element to which it is applied.
The test for the default color uses the injector of the second `<h2>` to get its `HighlightDirective` instance and its `defaultColor`.

* `DebugElement.properties` affords access to the artificial custom property that is set by the directive
52 changes: 26 additions & 26 deletions adev-es/src/content/guide/testing/attribute-directives.md
Original file line number Diff line number Diff line change
@@ -1,53 +1,53 @@

# Testing Attribute Directives
# Probar directivas de atributo

An *attribute directive* modifies the behavior of an element, component or another directive.
Its name reflects the way the directive is applied: as an attribute on a host element.
Una *directiva de atributo* modifica el comportamiento de un elemento, componente u otra directiva.
Su nombre refleja la forma en que se aplica la directiva: como un atributo en un elemento host.

## Testing the `HighlightDirective`
## Probar la `HighlightDirective`

The sample application's `HighlightDirective` sets the background color of an element based on either a data bound color or a default color \(lightgray\).
It also sets a custom property of the element \(`customProperty`\) to `true` for no reason other than to show that it can.
La `HighlightDirective` de la aplicación de muestra establece el color de fondo de un elemento basado en un color vinculado a datos o un color predeterminado \(lightgray\).
También establece una propiedad personalizada del elemento \(`customProperty`\) a `true` sin otra razón que mostrar que puede hacerlo.

<docs-code header="app/shared/highlight.directive.ts" path="adev/src/content/examples/testing/src/app/shared/highlight.directive.ts"/>

It's used throughout the application, perhaps most simply in the `AboutComponent`:
Se usa en toda la aplicación, quizás más simplemente en el `AboutComponent`:

<docs-code header="app/about/about.component.ts" path="adev/src/content/examples/testing/src/app/about/about.component.ts"/>

Testing the specific use of the `HighlightDirective` within the `AboutComponent` requires only the techniques explored in the ["Nested component tests"](guide/testing/components-scenarios#nested-component-tests) section of [Component testing scenarios](guide/testing/components-scenarios).
Probar el uso específico de la `HighlightDirective` dentro del `AboutComponent` requiere solo las técnicas exploradas en la sección ["Pruebas de componentes anidados"](guide/testing/components-scenarios#nested-component-tests) de [Escenarios de prueba de componentes](guide/testing/components-scenarios).

<docs-code header="app/about/about.component.spec.ts" path="adev/src/content/examples/testing/src/app/about/about.component.spec.ts" visibleRegion="tests"/>

However, testing a single use case is unlikely to explore the full range of a directive's capabilities.
Finding and testing all components that use the directive is tedious, brittle, and almost as unlikely to afford full coverage.
Sin embargo, probar un solo caso de uso es poco probable que explore el rango completo de las capacidades de una directiva.
Encontrar y probar todos los componentes que usan la directiva es tedioso, frágil y casi tan poco probable de ofrecer cobertura completa.

*Class-only tests* might be helpful, but attribute directives like this one tend to manipulate the DOM.
Isolated unit tests don't touch the DOM and, therefore, do not inspire confidence in the directive's efficacy.
Las *pruebas solo de clase* podrían ser útiles, pero las directivas de atributo como esta tienden a manipular el DOM.
Las pruebas unitarias aisladas no tocan el DOM y, por lo tanto, no inspiran confianza en la eficacia de la directiva.

A better solution is to create an artificial test component that demonstrates all ways to apply the directive.
Una mejor solución es crear un componente de prueba artificial que demuestre todas las formas de aplicar la directiva.

<docs-code header="app/shared/highlight.directive.spec.ts (TestComponent)" path="adev/src/content/examples/testing/src/app/shared/highlight.directive.spec.ts" visibleRegion="test-component"/>

<img alt="HighlightDirective spec in action" src="assets/images/guide/testing/highlight-directive-spec.png">
<img alt="HighlightDirective spec en acción" src="assets/images/guide/testing/highlight-directive-spec.png">

HELPFUL: The `<input>` case binds the `HighlightDirective` to the name of a color value in the input box.
The initial value is the word "cyan" which should be the background color of the input box.
ÚTIL: El caso `<input>` vincula la `HighlightDirective` al nombre de un valor de color en el cuadro de entrada.
El valor inicial es la palabra "cyan" que debería ser el color de fondo del cuadro de entrada.

Here are some tests of this component:
Aquí hay algunas pruebas de este componente:

<docs-code header="app/shared/highlight.directive.spec.ts (selected tests)" path="adev/src/content/examples/testing/src/app/shared/highlight.directive.spec.ts" visibleRegion="selected-tests"/>

A few techniques are noteworthy:
Algunas técnicas son dignas de mención:

* The `By.directive` predicate is a great way to get the elements that have this directive *when their element types are unknown*
* The [`:not` pseudo-class](https://developer.mozilla.org/docs/Web/CSS/:not) in `By.css('h2:not([highlight])')` helps find `<h2>` elements that *do not* have the directive.
`By.css('*:not([highlight])')` finds *any* element that does not have the directive.
* El predicado `By.directive` es una excelente manera de obtener los elementos que tienen esta directiva *cuando sus tipos de elemento son desconocidos*
* La [pseudo-clase `:not`](https://developer.mozilla.org/docs/Web/CSS/:not) en `By.css('h2:not([highlight])')` ayuda a encontrar elementos `<h2>` que *no* tienen la directiva.
`By.css('*:not([highlight])')` encuentra *cualquier* elemento que no tenga la directiva.

* `DebugElement.styles` affords access to element styles even in the absence of a real browser, thanks to the `DebugElement` abstraction.
But feel free to exploit the `nativeElement` when that seems easier or more clear than the abstraction.
* `DebugElement.styles` permite el acceso a los estilos del elemento incluso en ausencia de un navegador real, gracias a la abstracción `DebugElement`.
Pero siéntete libre de explotar el `nativeElement` cuando eso parezca más fácil o más claro que la abstracción.

* Angular adds a directive to the injector of the element to which it is applied.
The test for the default color uses the injector of the second `<h2>` to get its `HighlightDirective` instance and its `defaultColor`.
* Angular agrega una directiva al injector del elemento al que se aplica.
La prueba para el color predeterminado usa el injector del segundo `<h2>` para obtener su instancia de `HighlightDirective` y su `defaultColor`.

* `DebugElement.properties` affords access to the artificial custom property that is set by the directive
* `DebugElement.properties` permite el acceso a la propiedad personalizada artificial que se establece por la directiva
57 changes: 57 additions & 0 deletions adev-es/src/content/guide/testing/code-coverage.en.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@

# Find out how much code you're testing

The Angular CLI can run unit tests and create code coverage reports.
Code coverage reports show you any parts of your code base that might not be properly tested by your unit tests.

To generate a coverage report run the following command in the root of your project.

<docs-code language="shell">
ng test --no-watch --code-coverage
</docs-code>

When the tests are complete, the command creates a new `/coverage` directory in the project.
Open the `index.html` file to see a report with your source code and code coverage values.

If you want to create code-coverage reports every time you test, set the following option in the Angular CLI configuration file, `angular.json`:

<docs-code language="json">
"test": {
"options": {
"codeCoverage": true
}
}
</docs-code>

## Code coverage enforcement

The code coverage percentages let you estimate how much of your code is tested.
If your team decides on a set minimum amount to be unit tested, enforce this minimum with the Angular CLI.

For example, suppose you want the code base to have a minimum of 80% code coverage.
To enable this, open the [Karma](https://karma-runner.github.io) test platform configuration file, `karma.conf.js`, and add the `check` property in the `coverageReporter:` key.

<docs-code language="javascript">
coverageReporter: {
dir: require('path').join(__dirname, './coverage/<project-name>'),
subdir: '.',
reporters: [
{ type: 'html' },
{ type: 'text-summary' }
],
check: {
global: {
statements: 80,
branches: 80,
functions: 80,
lines: 80
}
}
}
</docs-code>

HELPFUL: Read more about creating and fine tuning Karma configuration in the [testing guide](guide/testing#configuration).

The `check` property causes the tool to enforce a minimum of 80% code coverage when the unit tests are run in the project.

Read more on coverage configuration options in the [karma coverage documentation](https://github.com/karma-runner/karma-coverage/blob/master/docs/configuration.md).
30 changes: 15 additions & 15 deletions adev-es/src/content/guide/testing/code-coverage.md
Original file line number Diff line number Diff line change
@@ -1,19 +1,19 @@

# Find out how much code you're testing
# Descubrir cuánto código estás probando

The Angular CLI can run unit tests and create code coverage reports.
Code coverage reports show you any parts of your code base that might not be properly tested by your unit tests.
Angular CLI puede ejecutar pruebas unitarias y crear reportes de cobertura de código.
Los reportes de cobertura de código te muestran cualquier parte de tu código base que podría no estar correctamente probada por tus pruebas unitarias.

To generate a coverage report run the following command in the root of your project.
Para generar un reporte de cobertura ejecuta el siguiente comando en la raíz de tu proyecto.

<docs-code language="shell">
ng test --no-watch --code-coverage
</docs-code>

When the tests are complete, the command creates a new `/coverage` directory in the project.
Open the `index.html` file to see a report with your source code and code coverage values.
Cuando las pruebas estén completas, el comando crea un nuevo directorio `/coverage` en el proyecto.
Abre el archivo `index.html` para ver un reporte con tu código fuente y valores de cobertura de código.

If you want to create code-coverage reports every time you test, set the following option in the Angular CLI configuration file, `angular.json`:
Si quieres crear reportes de cobertura de código cada vez que pruebas, establece la siguiente opción en el archivo de configuración de Angular CLI, `angular.json`:

<docs-code language="json">
"test": {
Expand All @@ -23,13 +23,13 @@ If you want to create code-coverage reports every time you test, set the followi
}
</docs-code>

## Code coverage enforcement
## Aplicación de cobertura de código

The code coverage percentages let you estimate how much of your code is tested.
If your team decides on a set minimum amount to be unit tested, enforce this minimum with the Angular CLI.
Los porcentajes de cobertura de código te permiten estimar cuánto de tu código está probado.
Si tu equipo decide sobre una cantidad mínima establecida para ser probada unitariamente, aplica este mínimo con Angular CLI.

For example, suppose you want the code base to have a minimum of 80% code coverage.
To enable this, open the [Karma](https://karma-runner.github.io) test platform configuration file, `karma.conf.js`, and add the `check` property in the `coverageReporter:` key.
Por ejemplo, supón que quieres que la base de código tenga un mínimo de 80% de cobertura de código.
Para habilitar esto, abre el archivo de configuración de la plataforma de pruebas [Karma](https://karma-runner.github.io), `karma.conf.js`, y agrega la propiedad `check` en la clave `coverageReporter:`.

<docs-code language="javascript">
coverageReporter: {
Expand All @@ -50,8 +50,8 @@ coverageReporter: {
}
</docs-code>

HELPFUL: Read more about creating and fine tuning Karma configuration in the [testing guide](guide/testing#configuration).
ÚTIL: Lee más sobre crear y ajustar la configuración de Karma en la [guía de pruebas](guide/testing#configuration).

The `check` property causes the tool to enforce a minimum of 80% code coverage when the unit tests are run in the project.
La propiedad `check` hace que la herramienta aplique un mínimo de 80% de cobertura de código cuando las pruebas unitarias se ejecutan en el proyecto.

Read more on coverage configuration options in the [karma coverage documentation](https://github.com/karma-runner/karma-coverage/blob/master/docs/configuration.md).
Lee más sobre opciones de configuración de cobertura en la [documentación de karma coverage](https://github.com/karma-runner/karma-coverage/blob/master/docs/configuration.md).
Loading