Visión general

En el artículo anterior , definí "Pruebas unitarias" y cómo podemos aplicar esas pruebas a nuestra aplicación Angular. Estamos de acuerdo en que, por definición, nuestra lógica comercial debe vivir fuera de nuestros componentes, y la mayor parte de nuestra funcionalidad vivirá en tuberías, directivas y servicios, lo que significa que la mayoría de nuestras pruebas unitarias probarán esos tipos de clases. En ese artículo, también publiqué una idea general de un componente Angular con su lógica de plantilla movida del componente a una canalización, dejando solo una Input()definición de clase y algunas plantillas. Todos estaríamos de acuerdo en que, en cualquier momento, alguien podría ingresar y agregar o eliminar elementos en el elemento, y no hay una cantidad de pruebas unitarias que puedan capturar esos cambios.

Por lo tanto, si no puede usar pruebas unitarias para probar un componente correctamente, solo le quedan pruebas de componentes, integración o de extremo a extremo.

La prueba de integración podría funcionar, pero por definición, la prueba de integración ocurre cuando prueba unidades individuales y las combina para probarlas como un grupo. Entonces, por ejemplo, podría probar ComponentAcon ComponentB, y eso probablemente esté bien en algunos casos. Pero, ¿qué sucede cuando te integras ComponentAcon ComponentC? ¿Se siente cómodo diciendo que la primera prueba que creó es lo suficientemente buena para enviar su producto a producción?

De acuerdo con los documentos angulares :

Los componentes básicos del marco Angular son los componentes Angular...

Los componentes están diseñados para ser combinados y consumidos por diferentes componentes para construir su aplicación. Por lo tanto, debe poder asegurarse de tener alguna fuente de verdad para el DOM, específicamente sus funciones Inputy Outputpropiedades de accesibilidad, y cualquier estilo que considere pertinente para asegurarse de que siempre sea válido y que no necesite probarlo. a mano.

Volvamos al componente Header:

A primera vista, no hay mucho que probar . En un mundo ideal, sabríamos que NameDisplayPipetiene pruebas que validan los valores proporcionados por el componente y devuelven lo que esperamos. Pero, ¿qué sucede si alguien ajusta accidentalmente el h1a un h2? ¿Qué sucede si alguien elimina accidentalmente la inicialización del título?

Pruebas de componentes al rescate

La prueba de componentes es increíble, ya que elimina la necesidad de probar manualmente muchas cosas que nos hemos acostumbrado a probar manualmente. Por ejemplo, solo conozco algunos desarrolladores que piensan en definir la estructura de la plantilla del componente (la parte más crucial) a través de pruebas; sin embargo, conozco muchos QA y diseñadores que verifican manualmente estas cosas. Sin embargo, es algo que generalmente no discutimos. Estamos convencidos de que probamos nuestra funcionalidad y comportamientos, pero solo nos interesa probar las plantillas una vez que el código está en producción. Es simplemente una ocurrencia tardía.

Supongamos que me dan un simulacro de una página con un encabezado, un cuerpo y un pie de página. Por el bien de este artículo, el contenido del cuerpo no importa, pero como un elemento de trabajo, debo hacer las tres cosas en un solo sprint. Entonces habría al menos cuatro componentes : a HeaderComponent, BodyComponent, FooterComponenty a PageComponentque integra a los otros tres…

Ya hemos creado el componente de encabezado, pero supongamos que no lo hicimos. Si tenemos maquetas del encabezado, podríamos definir lo que debería ser siempre cierto en este componente:

1. El componente debe envolver su contenido en un elemento de encabezado.
2. De forma predeterminada, si un usuario no ha iniciado sesión, el encabezado debe decir: "Hola, usuario" en un archivo h1.
3. Si un usuario ha iniciado sesión, el encabezado debe decir: "Hola, {{ Nombre de usuario }}" en un archivo h1.

Para las pruebas de componentes, puede usar Jasmine, Jest o Cypress. Con Jasmine y Jest, depende de TestBed y usa un accesorio para capturar elementos y reafirmarlos. Con Jest, no ves la plantilla en un DOM real, por lo que casi no brinda ningún beneficio real. Jasmine funciona muy bien aquí; Fuera de la caja, hace casi todo lo que usted quiere que haga. Es decir, poder caminar en el tiempo a través de las pruebas y ver instantáneas de sus pruebas. Como embajador de Cypress, probablemente haya adivinado que prefiero usar Cypress para esto, ¡y a partir de Cypress 10.5 podemos hacer que eso suceda!

TDD con prueba de componentes Cypress

Las pruebas de componentes de Cypress tienen una sintaxis muy similar a las pruebas de extremo a extremo de Cypress. Si sabe cómo escribir una "Prueba Cypress", sabe cómo escribir una prueba de componentes. Usando los 3 casos de prueba que creé anteriormente, puedo estructurar rápidamente un archivo de especificaciones de pruebas relacionadas con cada uno de ellos:

Si ha visto una prueba de Cypress en el pasado, esto debería parecerle bastante familiar. Si no lo has hecho, echemos un vistazo a cada pieza:

Debe estar dentro de un elemento de encabezado:

it('should contain a header', () => {    
  cy.mount(HeaderComponent);     
  cy.get('header')      
    .should('exist')      
    .should('be.visible');  
});

El cy.get('header')es el único comando siguiente. Usaremos javascript para obtener el elemento de encabezado y luego afirmaremos que no solo existe sino que también es visible. Esta prueba fallará al hacer TDD hasta que agreguemos un <header></header>elemento a la plantilla.

De forma predeterminada, si un usuario no ha iniciado sesión, el encabezado debe decir: "Hola, usuario" en un h1.

it('should have an h1 that has a greeting', () => {  
  cy.mount(HeaderComponent);     
  cy.get('h1')      
    .should('have.text', 'Hello, User');  
});

Si un usuario ha iniciado sesión, el encabezado debe decir: "Hola, {{ Nombre de usuario }}" en un h1.

it('should display a user name if name is provided', () => {    
  cy.mount(HeaderComponent, {      
    componentProperties: {        
      title: {          
        firstName: 'John',
        lastName: 'Doe'
      }      
    }    
  });       cy.get('h1')      
    .should('have.text', 'Hello, John Doe');
});

Fácil, ¿verdad?

Resumen

¡La prueba de componentes es interesante! No es un concepto nuevo, pero es más rápido de lo que teníamos acceso hasta la implementación de Cypress. Como puede ver en la parte superior derecha de ese panel izquierdo, se necesitan 147 ms para ejecutar esas tres pruebas, y cada prueba tarda menos de unos minutos en escribirse si la plantilla de su componente ya está definida. Con estas pruebas como punto de partida para este componente de encabezado, si alguien cambia algo que no está de acuerdo con las tres especificaciones que ya existen, sabemos que el componente está "roto" y debemos solucionarlo. Dado que esto solo está probando la instancia de HeaderComponent, no podemos llamarlo una prueba de integración. No podemos llamar a esto una prueba unitaria, ya que no se está probando ninguna funcionalidad. ¡Esto, mis amigos, es una prueba de componentes!

¿Era esto ya su comprensión de las pruebas de componentes en Angular? ¿Tus pruebas Jasmine o Jest son tan limpias y rápidas? ¡Déjame saber cómo el tuyo contrasta con esto!

Nos vemos en el próximo capítulo, donde revisaré las pruebas de integración.