Existen infinidad de nombres, y cada uno se refiere a un tipo concreto de test, donde cubre un tipo concreto de necesidades, y si a eso le sumas el rol encargado de mantener el test, la cosa se complica. La verdad, si tuviéramos que cubrir todos los aspectos usando los tests, la cantidad de tarea sería ingente… Entonces… ¿qué hacer?

Lo primero es saber identificar los tipos de tests más genéricos y reconocer su utilidad y características. Si no sabes que existe, no sabes que lo necesitas.

Ahora viene lo bueno… Tests hay para aburrir… como nos muestra la web de Guru99

En este artículo nos vamos a centrar los más usados y sobretodo, cuándo aplicarlos. Si tenemos una pieza pequeña de software que acaba de nacer, con funcionalidades básicas, no tiene sentido aplicar todo el stack de tests, sin embargo, a medida que el producto se hace maduro, es necesario aportarle un andamiaje para poder aplicar cambios y nuevas funcionalidades con seguridad.

Primer paso. Categorizar el tipo de test

Básicamente, hay dos tipos de test si lo miramos desde la perspectiva de los roles. Whitebox y BlackBox.

• Whitebox testing: Básicamente es la perspectiva del developer. Prueba el funcionamiento interno del código, framework, bases de datos, colas…
• Blackbox testing: Es la perspectiva del usuario. Interactúa con la pantalla como si fuera un usuario real usando la aplicación o hace llamadas a servicios si es una API. En el caso de simular una interacción de usuario suelen ser tests frágiles y por ello no es aconsejable apoyarse en ellos sin el resto de tests, ya que un cambio en la interfaz los puede hacer fallar aunque la aplicación funcione correctamente.

Una vez tenemos clara esta división, nos podemos adentrar a ver los tipos de test que forman estas dos categorías.

Los tests innegociables para un developer

Hay dos tipos de tests desde el punto de vista del developer que son innegociables por lo que nos aporta.

Test unitarios (Whitebox)

Los test unitarios son la pieza central del desarrollo orientado a TDD. Este tipo de enfoque basado en los tests unitarios nos asegura que nuestra pieza de software cumple los requisitos definidos en nuestra tarea y que aporta la funcionalidad justa y necesaria. Sin aportar más ni menos a la entrega.

Por otro lado, cumple una función muy importante a la hora de mantener la calidad en nuestro proceso creativo.

• Nos mantiene enfocados en la solución, sin importar cómo lo hagamos, y eso nos da la libertad de probar varios enfoques para llegar al la solución del problema.
• Cuando hemos encontrado una solución que nos satisface, nos permite refactorizar el código para dejarlo más limpio y ordenado teniendo la seguridad que no rompemos su funcionalidad, ya que los tests nos apoyan.

Ya te veo venir… si uno hace los tests para verificar el código… ¿quién verifica los tests?…. Pues ahí entra el concepto de “tests mutantes” (hablaremos de ello en otra ocasión).

Por otro lado, si enriqueces tu stack de tests con otro enfoque como los tests de tipo Blackbox, los cuales fuerzan a tu componente a interactuar con otra parte de código, tienes más posibilidades de encontrar ese caso en el que el código no se ajusta al comportamiento esperado y reformular los tests Whitebox para cubrir ese gap.

OJO!!! No te aventures a hacer TDD sin un mínimo diseño o esquema previo. Si no puedes terminar con un código difícil de leer, eso sí, testeado al 100%

Usa por ejemplo arquitectura hexagonal y patrones de diseño para tu implementación para saber qué objetos necesitas y dónde esperas crearlos.

Tests de integración (Whitebox)

Básicamente, se centra en testear el flujo de datos y las interfaces entre componentes. Los tests unitarios nos aseguran que nuestra pieza de software se ajusta a los requisitos establecidos, pero rara vez no forman parte de un conjunto mayor. En este caso entra en juego el test de integración. La idea detrás de este test es probar que los componentes trabajan correctamente fuera de sus fronteras del test unitario. Un ejemplo sería testear una clase con su Logger inyectado, a ver si trabajan bien juntos.

Los tests innegociables para asegurar el flujo y los datos.

Son los tests que vigilan la parte del usuario, y por ende, la perspectiva de negocio. Son los denominados System testing.

Este tipo de tests prueban toda la aplicación, desde el frontal hasta la base de datos. La idea es probar el código y la infraestructura para ver si el conjunto cumple su cometido.

Entre los System testing podemos encontrar más de 50 según la característica que queremos monitorizar, pero podríamos destacar los más usados, centrados en el flujo (también denominados funcionales):

• Smoke tests
• E2e (end to end)
• Tests de aceptación
• Tests de regresión

Smoke tests

El nombre de este test viene del la práctica de inyectar humo en las tuberías de agua para detectar fugas y evitar inundaciones.

Es un test muy básico orientado a asegurar que el flujo básico del producto sigue sin interrupciones. Tiene utilidad en las primeras fases de un producto, y aseguran un mínimo de calidad en el flujo de negocio.

End to end

Su objetivo es verificar que lo que se le envía al sistema a través de la interfaz de usuario o el acceso a la API retorna los valores esperados. Es un tests más completo. Dirigido a cubrir todas las casuísticas posibles.

Tests de aceptación

Este tipo de tests viene desde el punto de vista del usuario. Si los smoke tests cubrían la calidad del flujo, este tipo de test es más específico para asegurar que cumple los requisitos que un usuario necesita para que considere el producto como utilizable. Suele ser un test de tipo manual y requiere una interacción con el usuario, más un feedback del mismo para hacer los ajustes oportunos. Al final un test de aceptación acaba siendo un test de regresión al automatizarlo.

“Criterios de aceptación” no es lo mismo que “Tests de aceptación”:

Un criterio de aceptación tiene que ver con las historias de usuario, mientras que un test de aceptación es un acto de conciliación con el usuario, teniendo en cuenta aspectos que abarcan más allá de un criterio de aceptación, como usabilidad, visualización, velocidad…

Tests de regresión

La última capa nos asegura que un cambio en el código no genere bugs en zonas que no se han alterado. Aun teniendo tantas capas de tests como hemos visto antes, se nos puede escapar algo sutil y afectar a otra parte del comportamiento de la aplicación.

Lo complejo de este tipo de test es decidir la estrategia para implementarlo, ya que suelen ser extensos por la cantidad de combinaciones que pueden surgir. Este tipo de test exige que tengamos claro el flujo principal y los componentes que se van a ver afectados por el cambio, pero la estrategia que es innegociable es la siguiente:

Cuando encontramos un bug, lo primero que debemos hacer es crear un test que replique el problema y entonces arreglarlo. De esta forma nos aseguraremos que entendemos el problema, y de paso, que no vuelve a producirse en el futuro.

Links y recursos

https://es.wikipedia.org/wiki/Pruebas_de_software

https:/www.guru99.com/types-of-software-testing.html