Hacer tests tolerantes al cambio en Angular usando SCAMs

Traduccin en espaol del artculo original de Tim Deschryver Single Component Angular Modules and Component Tests go hand in hand publicado el 17 marzo 2022

Escribir buen test no es tan simple como parece, se necesita algo de orientacin y prctica para hacerlo bien. Uno de los factores clave que hacen que una buena prueba se destaque es la parte de organizacin (o configuracin).

Para realizar test a los componentes en Angular, hacer mdulos de nuestros componentes (Single Component Angular Modules) versin corta (SCAMs) ayudan a marcar la diferencia entre un test y un buen test.

Utilizando SCAMSs, podemos hacer que nuestros test no sean tan frgiles a los cambios, lo cual hace que el equipo no tenga miedo a cambiar cosas.

Estoy seguro de que un equipo anterior del que form parte podra haberse beneficiado de los SCAMs y haban tenido menos frustracin al hacer cambios en nuestros componentes sin afectar los tests.

La mayora de los cambios en un componente solo requieren algunos minutos para que un desarrollador experimentado se asegurara de que los tests se pasaran nuevamente. Mientras que un nuevo desarrollador a menudo miraba las pruebas fallidas sin saber qu hacer que ha cambiado o que fallaba el test.

En la mayora de los casos, esto no tiene sentido porque el componente estaba funcionando, pero despus de algunas veces de corregir el test ya estaba ms claro, pero no era ideal y era costoso para todos.

SCAMs nos da la respuesta a este problema y en usando junto a Angular Testing Library hace sper fcil y divertido hacer pruebas a nuestros componentes.

Miremos un ejemplo Podemos pensar en cambios en el componente MyAwesomeComponent pueden romper renderizado y, por lo tanto, hacen que la prueba falle?

it('renders the MyAwesomeComponent component', async () => {  await render(MyAwesomeComponent, {    imports: [      MatButtonModule,      MatDialogModule,      MatInputModule,      MatTableModule,      MyAwesomeSharedModule,    ],    declarations: [MyAwesomeChildComponent, MyAwesomeGrandChildComponent],    providers: [      {        provide: EntityService,        useValue: mock(EntityService),      },    ],  });  // ... Lo que sigue del test esta aqui ...});

Puedes pensar varias razones por la cual el test falla, algunas serian por ejemplo:

• Un nuevo mdulo se utiliza en el componente MyAwesomeComponent
• MyAwesome component est utilizando un nuevo componente hijo.
• Quizas un componente hijo de nuestro MyAwesomeComponet est usando un nuevo componente.
• Un componente fue eliminado.
• MyAwsomeComponent lo han agregado en MyAwesomeShareModule

Muchas opciones no?

MODULARIZAR LOS COMPONENTS ES UNA SOLUCION.

Para hacer que nuestros tests sean ms tolerantes a los cambios y no tan frgiles, nosotros podemos utilizar SCAMs, con los SCAMs los cambios de nuestros componentes o directivas estn encapsulados con su mdulo.

Como el mdulo es importando en el test, la configuracin se actualiza de forma automtica.

Sin meternos en ms detalles sobre SCAM, un componente modula rizado se ver de la siguiente manera:

Si quieres leer mas sobre Single Component Angular Modules SCAMs (en ingles) por Lars Gyrup Brink Nielsen

@NgModule({  declarations: [MyAwesomeComponent],  exports: [MyAwesomeComponent],  imports: [    MatButtonModule,    MatDialogModule,    MatInputModule,    MatTableModule,    MyAwesomeSharedModule,    MyAwesomeChildComponentModule,    MyAwesomeGrandChildComponentModule,  ],})export class MyAwesomeComponentModule {}

CONFIGURACIN CON EXCLUDECOMPONENTDECLARATION

Utilizamos la funcin render de testing library e importamos el mdulo. Para evitar que el componente se agregue de manera automticamente a las declaraciones de TestBed, utilizamos la propiedad excludeComponentDeclaration.

it('renders the MyAwesomeComponent component', async () => {    await render(MyAwesomeComponent, {        excludeComponentDeclaration: true,        imports: [MyAwesomeComponentModule],        providers: [            {                provide: EntityService,                useValue: mock(EntityService),            },        ],    });    // ... lo que continua del test esta aqui...});

CONFIGURACIN GLOBAL DE EXCLUDECOMPONENTDECLARATION

Cuando nuestro equipo use SCAM por defecto, la propiedad excludeComponentDeclaration se puede configurar globalmente mediante el mtodo configure en test.ts.

import { configure } from '@testing-library/angular';configure({    excludeComponentDeclaration: true,});

Nuestro test se ver de esta manera

t('renders the MyAwesomeComponent component', async () => {    await render(MyAwesomeComponent, {        imports: [MyAwesomeComponentModule],        providers: [            {                provide: EntityService,                useValue: mock(EntityService),            },        ],    });});

USANDO EL COMPONENTE COMO TEMPLATE

Tambin puede utilizar el template, en lugar del el tipo representar el componente. Esto no requiere asignemos la propiedad excludeComponentDeclaration.

t('renders the MyAwesomeComponent component', async () => {    await render(`<my-awesome-component></my-awesome-component>`, {        imports: [MyAwesomeComponentModule],        providers: [            {                provide: EntityService,                useValue: mock(EntityService),            },        ],    });});

CONCLUSIN

Si bien las SCAM tienen muchas caractersticas positivas, los beneficios que brindan a los test de componentes unas de mis favoritas. Desde mi experiencia, ha sido un placer y me siento ms productivo que antes.

Al organizar los componentes bsicos en SCAM, nuestros tests no necesita averiguar qu dependencias se requiere o tener que los test. Con SCAM, cada cambio en el cdigo de del componente se refleja directamente en nuestros tests.

Si sigue esta prctica, nuestros tests se vuelven resistentes a los cambios internos y concentrarnos por completo en las nuevas funciones.

OPINION PERSONAL

Utilizar SCAMs nos quita muchos dolores de cabeza y el miedo de romper los tests, a la ms mnima de cambios, ya que es muy frustrante, puesto que cada cambio de nuestro cdigo se refleja en el test y genera doble trabajo.

Espero que esto les ayuda a escribir tests ms tolerantes al cambio.

Photo by Hkon Grimstad on Unsplash