Cómo escribir pruebas unitarias

Como programador principiante, a menudo escucharás que es conveniente probar tu código. Es un buen consejo - ¡veamos cómo puedes empezar a hacerlo!

Qué son las pruebas unitarias

Las pruebas son una forma de fijar explícitamente expectativas sobre el código. Las estableces para que la máquina compruebe si tu código cumple con las expectativas.

Es un programa que verifica tu programa.
Normalmente, en los proyectos de JavaScript, usarás alguna biblioteca de pruebas, como:

• Jest,
• Jasmine, o
• Chai

Pero éstas son sólo herramientas. Lo que importa es que tengas alguna forma de validar automáticamente tu aplicación.

Cómo te ayudan las pruebas unitarias

Hay cuatro razones por las que escribir pruebas te facilitará la vida a la hora de codificar:

1. Es una forma rápida y fiable de comprobar si el código funciona como se esperaba. No tienes que pensar en casos límite para tenerlos todos cubiertos por pruebas unitarias.
2. Una buena cobertura de pruebas es una red de seguridad que te permite refactorizar el código con más arrojo. Así es más probable que tomes las medidas necesarias para mantener tu código base en buenas condiciones.
3. Escribir pruebas unitarias te obliga a pensar en las unidades y en cómo se debe repartir la carga entre ellas, lo que hace que tu código sea más modular y más fácil de mantener.
4. Las pruebas unitarias pueden convertirte en un programador más rápido. Al principio, tienes que invertir tiempo en crear el caso de prueba, pero una vez que está listo, puedes volver a ejecutarlo de forma muy económica. La inversión puede pagar dividendos incluso durante el desarrollo inicial.

Construir un andamiaje

Antes de probar la funcionalidad, asegúrate de que puedes probar cualquier cosa. Instala la biblioteca de pruebas y crea tu script de pruebas. Una vez que tengas algo en marcha, puedes empezar a configurar el andamiaje para algunas de tus pruebas. Tienes que tomar una decisión sobre la nomenclatura. Por ejemplo, si tu código es mi-proyecto/plane-ticket.js, tu código de pruebas puede ubicarse en mi-proyecto/plane-ticket.spec.js.

Construye todo lo necesario para probar una clase cualquiera y luego comprueba algunos aspectos comunes:

• si un objeto es un objeto, o
• si una función es una función

De esta manera, demostrarás que puedes probar cosas.

Configurar los mocks

Los mocks son objetos creados para reemplazar las dependencias de la unidad que estás probando. Por ejemplo, si pruebas la función saveBlogPost, querrás interceptar la petición HTTP antes de que la función la envíe. Querrás averiguar qué utiliza tu función para enviar la petición y sustituirlo por un mock. Esto debería ser fácil si construyes tu código usando un patrón de inyección de dependencia.

Mantener una estructura

Como podrás ver, en cada prueba ocurren muchas cosas. Se pueden distinguir tres fases principales:

1. Configuración de los mocks
2. Ejecución del código que se quiere comprobar
3. Comprobación de las expectativas

Es lógico mantener esta separación en tu código; será más fácil de leer de esta manera. Una forma fácil de organizarlo es agrupando todas las líneas y quizás añadiendo un comentario especificando de qué parte se trata.

Desarrollo guiado por pruebas

El desarrollo guiado por pruebas es un procedimiento común para crear un buen código con una buena cobertura de pruebas. Empiezas añadiendo una prueba para una función antes de que se implemente. Ejecutadas las pruebas, debería de fallar - si no es así, algo grave estará pasando y tendrás que investigar qué es. Las pruebas fallan y agregas al código la implementación que falta. Una vez más, se espera que esto por sí solo solucione el fallo. Si todo va bien, inviertes un poco de tiempo en optimizar tu solución, tanto en el código como en las pruebas, sin cambiar la lógica. Esta forma de proceder te permite iterar rápidamente en la creación del código y sus pruebas.

Si sigues esta práctica, nunca se te podrá escapar ninguna prueba para tu lógica. No tendrás la tentación de saltarte la escritura de pruebas, un problema común cuando se deja la escritura de pruebas para el final.

Contra-recomendación

Para ser un líder, hay que saber a dónde vas. Deja de lado las pruebas durante un tiempo si necesitas explorar qué soluciones son factibles. Una vez que tengas claro el camino, puedes agregar pruebas o abordar el problema de nuevo de una manera guiada por pruebas.

Pruebas que faltan

Si tienes mala suerte, puede que estés trabajando con código heredado sin pruebas ni otras medidas de calidad, algo así como lo que describo aquí. En tal caso, más vale tarde que nunca; puedes empezar a escribir pruebas a medida que trabajas con el código base. De esta manera, mejoras la situación de cara a un futuro y en algunos casos excepcionales, tal vez encuentres algún error oculto.

¿Y tú?

¿Cómo de difícil te parece aprender a probar? He visto quejas en Internet de personas a las que les cuesta encontrar buenos recursos para ello. Cuéntame qué experiencias has tenido hasta ahora.