Enfoque de los tests en Frontend
Lo que vas a leer a continuación aplica a los tests de desarrollo, los cuales expliqué en el artículo anterior, a excepción de los tests estáticos. Es decir, cuando hablo del enfoque de un test, me refiero al enfoque que debe seguir el desarrollador a la hora de escribirlo.
El prisma
Al otro lado de la pantalla hay personas, como tú y como yo, usando la aplicación. Por ese motivo, es imprescindible que los tests de la parte de Frontend se escriban pensando en el usuario.
Teniendo esto en cuenta, cuando escribas un test, pregúntate:
¿Qué es lo que el usuario puede ver?
¿Qué es lo que el usuario puede hacer?
¿Cómo se comporta la aplicación en un estado diferente al esperado?
Ejemplo
Veamos un ejemplo: dado un componente imaginario llamado ProductCard, el cual es una tarjeta de producto que aparece en un listado de una tienda en línea.
¿Qué es lo que el usuario puede ver?
- El nombre del producto
- El precio del producto en el formato correcto
- La imagen del producto
- El botón de "Agregar al carrito"
- La valoración del producto
- etc.
¿Qué es lo que el usuario puede hacer?
- Puede hacer clic en el botón de "Agregar al carrito" y, cuando lo hace, se agrega el producto al carrito.
- Puede hacer clic en el nombre del producto para ver más detalles y, cuando lo hace, se redirige a la página de detalles del producto.
- etc.
¿Cómo se comporta la aplicación en un estado diferente al esperado?
- El usuario no puede ver el producto si no está disponible.
- El usuario no puede agregar el producto al carrito si no hay stock.
- El usuario no puede ver la valoración del producto si no hay valoraciones.
- etc.
¿Me sigues?
Para ser más explícito, te dejaré algunos ejemplos de cosas que el usuario no ve y no entiende, pero que el desarrollador sí. Son cosas que no deberían comprobarse de forma explícita, pero que sí se validan de manera indirecta:
- Que el componente tenga una clase o estilo CSS en particular.
- Que al hacer clic en un botón se llame a una función en particular.
- Que se haga una petición HTTP al servidor.
- Que se guarde algún valor en un estado.
Excepciones
Te voy a explicar algunos casos en los que puede haber excepciones. No todo debe ser blanco o negro; a veces debemos jugar con la gama de grises.
Cuando alguna parte de nuestro código utiliza APIs del navegador, en ocasiones debemos comprobar detalles de implementación que el usuario desconoce, con el fin de mantener una buena cobertura de casos de uso y favorecer la simplicidad en los tests.
Un ejemplo sería la navegación. No es necesario comprobar el lugar de destino exacto de la navegación; con verificar que se ejecute correctamente el trigger que hace que el navegador cambie de página, sería suficiente.
Como este, seguro encontrarás más casos concretos que deberán ser considerados de forma aislada e independiente, dependiendo de los tradeoffs que queramos asumir.
El enfoque de un test en Frontend
Teniendo en cuenta, y aplicando, el prisma detallado en el punto anterior, el enfoque de un test debe dirigirse a verificar los casos de uso concretos de la pieza de código a testear, omitiendo los casos de uso de las piezas que se integran en ella.
De esta forma, definiendo una buena composición de la interfaz, podremos tener muchas piezas pequeñas, fáciles de testear y que, al juntarlas, formen una aplicación robusta y fiable.
Ejemplo
Para verlo más claro, pondré un ejemplo utilizando el componente ProductCard mencionado anteriormente.
Imaginemos que este componente se compone de:
- Componente
<Image /> - Componente
<Rating /> - Componente
<Price /> - Componente
<Typography /> - Componente
<AddToCardButton />
¿Qué deberíamos testear en el componente "ProductCard"?
- Que el usuario vea la información del producto, es decir, la imagen, el nombre, el precio, la valoración y el botón de "Agregar al carrito".
¿Qué no deberíamos testear en el componente "ProductCard" y por qué?
- Que el componente
<Image />muestre un placeholder mientras carga la imagen. Esto formaría parte de los tests del componente<Image />. - Que el componente
<Rating />muestre el número de estrellas amarillas correctamente. Esto formaría parte de los tests del componente<Rating />. - Que el componente
<Price />muestre el precio en el formato correcto. Esto formaría parte de los tests del componente<Price />. - Que el componente
<AddToCardButton />añada el producto al carrito. Esto formaría parte de los tests del componente<AddToCardButton />.
Cobertura
No me gusta la palabra "cobertura" e intento utilizarla lo menos posible. En caso de hablar de ella, es necesario matizar y dar contexto.
Entiendo por cobertura la cantidad de casos de uso que se han testeado, incluyendo comprobaciones de rendimiento, accesibilidad, SEO, etc., y no la cantidad de líneas de código que se han ejecutado.
Hablar de cobertura como el número de líneas de código que se han ejecutado es un error, ya que no garantiza que se hayan verificado todos los casos de uso y, por ende, no asegura el correcto funcionamiento de la aplicación.