La pirámide de los tests automáticos

Aquí estamos con un nuevo post, en este caso vamos a tratar un tema de buenas prácticas de testeo de código. Trataremos sobre la pirámide de los tests automáticos (testing pyramid).

Pirámide de tests automáticos - Testing Pyramid - jrgonzalez.es

fuente de la imagen

¿Qué es la pirámide de los tests automáticos o testing pyramid?

Testing Pyramid es un marco que puede ayudar tanto a los desarrolladores como a los QA a crear software de alta calidad. Esto es una de las ventajas de los tests automáticos de código, el incremento de la calidad del mismo.

Reduce el tiempo necesario para que los desarrolladores identifiquen si un cambio que introdujeron durante el desarrollo rompe el código. Además puede resultar útil para crear un conjunto de pruebas automáticas y fiables con las que poder garantizar una buena cobertura de código y casos de uso.

La pirámide de pruebas, también conocida como la pirámide de automatización de pruebas, establece los tipos de pruebas que deben incluirse en un conjunto de pruebas automatizado.

También describe la secuencia y frecuencia de estas pruebas. El objetivo es ofrecer información de errores de manera inmediata para garantizar que los cambios en el código no rompen el código existente.

La pirámide de tests automáticos o automatización de pruebas está dividida en tres niveles:

  • Unit tests (Pruebas unitarias)
  • Integration tests (Pruebas de integración)
  • End to End tests (Pruebas funcionales)

Además de las pruebas anteriores, siempre se pueden añadir pruebas manuales.

Unit tests (tests unitarios)

Las pruebas unitarias son la base de la pirámide de pruebas.

Estos tests unitarios son los encargados de testear componentes o funcionalidades individuales para validar que funciona de la manera esperada en condiciones aisladas.

Es importante ejecutar una serie de escenarios en pruebas unitarias:

  • Caso de éxito
  • Casos de error
  • Gestión de excepciones
  • Comprobar cada uno de los flujos de salida/entrada de una propia funcionalidad

Dado que este es el subconjunto más grande, el conjunto de pruebas unitarias debe escribirse para que se ejecute lo más rápido posible. Además debemos de asegurar que las pruebas unitarias no tienen ninguna dependencia con la aplicación, es decir que no accedan ni a datos reales ni necesiten de una base de datos o un servicio activo. Deben de ser pruebas unitarias e independientes.

La cantidad de pruebas unitarias aumentará a medida que se agreguen más funcionalidades en una aplicación. Este conjunto de pruebas debe ejecutarse cada vez que se agrega una nueva función.

En consecuencia, los desarrolladores reciben comentarios inmediatos sobre si las funciones están funcionando como deben y no interfieren con el comportamiento esperado del código.

Muchos frameworks como Laravel tienen incluso comando específicos de Artisan para ejecutar los tests.

Metodologías de desarrollo basadas en test unitarios

Dando por hecho que tener a mano un set de pruebas y test unitarios ánima a los desarrolladores de código a hacer pruebas y comprobar que el código que están generando funciona y se complementa correctamente con el código existente.

TDD o desarrollo de código basado en tests

Una buena forma de crear un conjunto de pruebas unitarias sólido es practicar desarrollo de código basado en tests (TDD).

Dado que TDD requiere que se escriba una prueba antes de cualquier código, el código termina siendo más simple, más claro y libre de errores.

Aunque ello implique un cambio en el paradigma de desarrollo, los beneficios de tener un código testeable serán los bastantes como para asumir el tiempo empleado anteriormente para crear estos tests.

Integration tests (tests de integración)

Las pruebas de integración son la segunda capa de la pirámide de automatización de pruebas. Y se encargan de comprobar la compatibilidad del código.

Mientras que los tests unitarios verifican pequeños fragmentos de código los tests de integración prueban cómo interactúa un código con otro código. Es decir, comprueban la compatibilidad del código.

Básicamente, se trata de pruebas que validan la interacción de un fragmento de código con componentes externos. Estos componentes pueden variar desde bases de datos, APIs y similares fuentes de información.

Esto significa que no deben ejecutarse con tanta frecuencia como los tests unitarios. Ya sea que se trate de una llamada a una base de datos o un servicio web, el software necesita comunicarse de manera efectiva y recuperar la información de manera correcta como se espera.

Dado que las pruebas de integración implican la interacción con servicios externos, se ejecutarán más lentamente que las pruebas unitarias. También requieren un entorno de preproducción en el que funcionar. Además de preparar un conjunto de datos de entrada/salida preparado para el trabajo y la verificación de los tests.

End to End tests (Tests funcionales)

La parte más superior de la pirámida está compuesta por los tests funcionales. Estos aseguran que toda la aplicación funcione acorde a lo esperado.

Los tests funcionales hacen exactamente lo que sugiere el nombre: comprueban que la aplicación funciona sin problemas de principio a fin.

A la hora de ejecutar este tipo de tests lo más importante es tener empatía y ponerse en la perspectiva del usuario.

  • ¿Cómo interactuaría un usuario real con la aplicación?
  • ¿Qué resultados espera al tratar con la aplicación?
  • ¿Aseguramos que siempre haya una respuesta al realizar una acción?
  • ¿Cómo se pueden escribir pruebas para replicar esa interacción?

Los tests funcionales son las que más tardan en ejecutarse. También pueden ser frágiles y estar muy condicionados ya que tienen que probar una gran variedad de escenarios de usuario bastante definidos.

Al igual que las pruebas de integración, estas pruebas también pueden requerir que la aplicación se comunique con dependencias externas, lo que se suma a posibles cuellos de botella al finalizar.

Normalmente, las dependencias externas se «mockean», es como falsear los resultados a través de pruebas y usar las respuestas obtenidas durante pruebas en test o en entornos en vivo.

Resumen

En este post hemos aprendido acerca de la pirámide de tests automáticos.

Así como los beneficios de los tests y una idea inicial de cada uno de los tipos de tests.

En futuros posts podremos pasar a destripar cada tipo de tests de una manera más profunda, así como ejemplos de cada uno de estos tests.

Comparte 🙂

Si te ha gustado el contenido de este artículo no te olvides de compartirlo ya que con eso me harías muy feliz. GRACIAS 😉

Participa 😉

Además de todo ello, si tienes dudas o puedes aportar algo con un comentario, no dudes en hacerlo. GRACIAS 😉

¿Y tú qué opinas?

Antes de participar en los comentarios, ten en cuenta que leeré personalmente cualquier cosa que escribas. Así que, por favor, mantén las formas y compórtate como una persona de bien.

  • (will not be published)

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>