¿Qué pruebas automatizadas implementar en mi desarrollo?

El nivel de robustez de tus sistemas es claramente el grado de presión de cada una de las pruebas implementadas. En este artículo describiremos algunas de las mejores prácticas para poner a prueba la robustez del desarrollo de tus sistemas.

Antes de continuar con la lectura, ¿recuerdas TDD? Hace unas semanas Chiyana nos invitaba a reflexionar con la pregunta “¿Qué problema hay en utilizar TDD?”, una lectura obligatoria.

Para verificar la precisión de tu aplicación podemos utilizar diferentes tipos de pruebas: algunas verifican la lógica de algún pequeño servicio o clase, otras verifican cada una de las capas de tu sistema desde el frontend hasta las bases de datos e incluso verificando servicios externos. El número de componentes probados en tu sistema define el alcance de la prueba: menos componentes, menor alcance, y más componentes, mayor alcance. Cuanto mayor sea el alcance de las pruebas más recursos te harán falta, tanto de infraestructura como de programación.

¿Por qué implementar pruebas en mis sistemas?

No sólo te ayudarán a probar tu desarrollo para encontrar cualquier incongruencia en el sistema, también para que tu desarrollo sea mantenible. La capacidad de mantenimiento de tu sistema es la capacidad de comprender, cambiar y probar tu sistema de forma eficaz.

Tal como nos explicó claramente Chiyana en TDD, el argumento más común en contra de estas pruebas es el tiempo. Es cierto que es complicado pero a medida que avances en tu desarrollo e implementes nuevas funcionalidades, te verás con la necesidad de refactorizar código antiguo y asegurarte que los nuevos cambios no afecten al funcionamiento definido en tu modelo de negocio; por eso deberías contar con pruebas en tu sistema.

Al escribir las pruebas automatizadas es extremadamente importante que todas se realicen siguiendo la documentación de tu sistema o API para que estén centradas a tu modelo de negocio.

¿Qué debería tener en cuenta al desarrollar pruebas en mis sistemas?

No existen fórmulas mágicas que dicten cómo probar tu sistema. Cada capa o componente de tu sistema requerirá la herramienta adecuada. El desafío es identificar los errores que pueden afectar a cada componente para encontrar la combinación correcta de pruebas que cubran todos los aspectos funcionales y técnicos de tu sistema.

Veamos 4 consideraciones que deberías tener en cuenta a la hora de escoger los mejores métodos de prueba:

1 - FIABILIDAD: ¿Es fiable la prueba?

Debes tener en cuenta que la respuesta de cada prueba responda aquello que necesites. Verifica que la prueba indicará si el sistema contiene algún error y cuál. Es vital para responder adecuadamente a las alertas que generen tus pruebas implementadas, y es por ello que debes escoger el sistema que más fiabilidad aporte como respuesta al estado de tu programación.

2 - COSTES: ¿Cuánto me costará desarrollar y mantener estas pruebas? ¿Y cuánto si no las aplico?

¿Por qué desarrollar pruebas si entorpecen el ritmo de mi desarrollo? Tal como nos indico Chiyana en TDD, muchas veces se empieza a desarrollar sobre un problema sin saber exactamente qué es lo que se está solucionando. ¿Para qué ejecutar tests si no se sabe el camino? En esta situación los tests se convierten muy rápidamente en una carga con costes elevados.

Pero si tu proyecto está definido, las pruebas te garantizarán un sistema robusto, tan robusto como pruebas implementes, además que garantizarán futuras versiones más robustas.

3 - VELOCIDAD: ¿Las pruebas se ejecutan rápido?

Las pruebas deben ser rápidas, ya que deben formar parte de tu pipeline CI/CD. Cada vez que implementes un cambio en tu sistema deberían ejecutarse las pruebas garantizando el correcto funcionamiento de tu nueva release.

Si no ejecutas con frecuencia las pruebas no podrás verificar a tiempo posibles problemas para solucionarlos de forma fácil y rápida.

¿Qué pasaría si las pruebas fueran muy lentas? Exactamente, de ese modo no las ejecutarías tanto como se requiere; imagina que tu pipeline CI/CD, además de ejecutar la compilación (entre otras tareas, con el tiempo que eso conlleva), tuviera que esperar más de 5 minutos en cada nueva verificación... ¿tu organización puede permitirse este tiempo en el despliegue de un parche de seguridad?

4 - OBJETIVO: ¿La prueba ayudará al equipo a desarrollar en la dirección correcta?

El objetivo de las pruebas no es mostrar errores de programación. Tratan de determinar el estado del desarrollo respondiendo a los problemas lo más rápido posible. Es por ello por lo que las pruebas deben tener un objetivo claro, proporcionando comentarios explícitos sobre los errores o problemas definidos.

¿Qué métodos de pruebas implemento en mis sistemas?

Según el grado de precisión que desees tener en tu desarrollo podemos utilizar diferentes métodos de pruebas, así que antes de responder a la pregunta de este apartado veamos los 3 métodos de pruebas más comunes:

Pruebas unitarias (Unit tests)

El objetivo de las pruebas unitarias es probar funcionalidades concretas del sistema. Pongamos un ejemplo: si cocinamos una tarta, una “unidad de prueba” podría ser el azúcar, la harina, los huevos, las manzanas… mmm... ¡cómo recuerdo la deliciosa la tarta de manzana de mi abuela!

Cada “unidad de prueba” es una pieza funcional del desarrollo y no tiene mucho sentido fuera de contexto. Entonces el objetivo de esta prueba, siguiendo con la metáfora de la tarta, es verificar si realmente es dulce o no, para verificar que realmente añadimos azúcar y no sal. Aunque las pruebas unitarias por sí mismas no garantizan que la tarta sea realmente buena, este método de prueba te proporciona información granular que será muy útil para el desarrollador, indicándole y verificando cada ingrediente.

Pruebas E2E “extremo a extremo”

Muy bien, parece que tenemos todos los ingredientes preparados, pero… ¿cómo verifico la preparación de mi tarta? La verificación de tu modelo de negocio es importante, tienes la mejor tarta del mundo, por eso probar la receta es importante. Las pruebas E2E recogerán todos los ingredientes verificados en el método de pruebas unitarias para comprobar si realmente se trata de la receta de tarta de manzana definida, verificando que tu modelo de negocio programado cumple con los requisitos.

Pruebas de integración

Ahora que tenemos la tarta definida, las pruebas de integración verifican la capacidad de tu desarrollo de poder funcionar adecuadamente. ¿La textura es la adecuada? ¿Es el sabor adecuado?

El objetivo es verificar si una entrada de datos devuelve la respuesta esperada. Como por ejemplo: los usuarios inician sesión, insertan un dato que se guarda en la base de datos y cierran sesión. La prueba debe asegurar de que el escenario es el esperado.

Ahora que conocemos los 3 métodos más comunes, veamos qué métodos de pruebas puedes implementar en tu sistema teniendo en cuenta las 4 consideraciones del apartado anterior.

Conclusión

Las pruebas son todo un desafío, ya que no existe una regla definida que marque tu desarrollo. Deberás valorar la combinación correcta de pruebas que permita comprobar el comportamiento de tu sistema, aportando fiabilidad, retorno de costes al implementar nuevas versiones de tus sistemas, velocidad de verificación y un claro objetivo que marque el camino a tus desarrolladores.

¿Aplicas TDD en tus desarrollos? ¿Qué método implementas? ¿Aplicas prueba continua en tu pipeline CI/CD?

Photo by Sebastien Gabriel on Unsplash