INTRODUCCIÓN
Tras la charla “Isolated vs Integrated tests” que presenté en el Open Space de la WeCode 2020 pedí feedback a varios compañerxs y amigxs de la comunidad. Entre ellos a Eduardo Ferro, persona muy respetada por su experiencia y con el que he coincidido en varios eventos, además de haber podido participar en un debate en NorthemQuality.
Podéis ver el debate (QA y principios XP, ¿Juntos o Revueltos?) en los vídeos de la primera temporada.
Mi idea principal era presentar esta charla en la T3chFest, pero la descartaron. Menos mal, no me hubiera dado tiempo, además de poder llegar a ser muy densa. Lo primero que me dijo Edu cuando le pedí feedback fue: “No te daba tiempo ni de palo” (aunque creo que lo de “ni de palo” lo he añadido yo a mis recuerdos).
Edu me comentó que la idea era interesante y que se había apuntado algunas cosas, pero que podía llegar a costar ver las diferencias entre las pruebas integradas y aisladas, en definitiva, que podría llegar a ser un poco lío.
Me recomendó hacer varios gráficos que representarán la idea que quería exponer, gráficos con varias dimensiones para ver las diferencias entre cada tipo de prueba.
Me puse a darle vueltas, se me ocurrieron varios gráficos con distintas dimensiones y de aquí nació esta serie de posts..
Os dejo un enlace de este mismo blog para aquellas personas que no conozcan de qué tratan las pruebas integradas y aisladas.
En esta serie de posts vamos a hacer la comparativa entre varios tipos de prueba. En el testing existen un número elevado de técnicas, para el artículo he elegido las siguientes:
- Pruebas unitarias.
- Pruebas de contrato.
- Pruebas de integración integradas.
- Pruebas aisladas de integración: A diferencia de la pruebas de integración, en las aisladas en vez de conectar con los colaboradores reales, vamos a conectar con componentes (stubs) para simular su conexión.
- Pruebas funcionales integradas.
- Pruebas funcionales aisladas: Al igual que en las pruebas aisladas de integración, haremos uso de stubs para simular la funcionalidad de los colaboradores y así no depender de ellos.
- Pruebas funcionales de soporte: Nos van a servir para detectar aquellos bugs que no deberían bloquear la release. Suelen emplearse como complemento a las funcionales integradas y aisladas.
- Pruebas exploratorias.
- Pruebas funcionales en producción: Pruebas que intentan verificar una funcionalidad en producción, normalmente para comprobar el estado de la aplicación.
Vamos a ello!
GRADO DE CONFIANZA DE LAS PRUEBAS
La dimensión que vamos a tratar en este post es la del grado de confianza de las pruebas.
Cuando hablamos de grado de confianza, estamos hablando de la capacidad de detección de bugs de una prueba. Lo importante es conocer el área de impacto de la prueba en nuestra aplicación, cuanto más impacte, más grado de confianza podrá darnos. Vamos a diferenciar dos tipos de área de impacto:
- Área de impacto principal (MIA): Es el área objetivo de la prueba.
- Área de impacto secundario o área de impacto irradiada (IIA): Es el área que se ve afectada sin ser objetivo principal de la prueba.
Lo vamos a entender mejor en el siguiente análisis por cada tipo de pruebas. En las siguientes imágenes tenemos representada una aplicación con arquitectura hexagonal, veamos las áreas de impacto de los diferentes tipos de pruebas aisladas e integradas.
Área de impacto en pruebas de integración integradas y aisladas
En las pruebas de integración integradas, vemos cómo el área de impacto principal (MIA) afecta a la BD y a la clase que implementa la integración con la BD (repository adapter).
Tiene sentido, puesto que es lo que queremos comprobar en este tipo de pruebas, pero la capa de dominio se ve afectada en nuestra aplicación debido a que en nuestro ejemplo accedemos a las clases de dominio en el repository adapter. Este área es identificada como área de impacto irradiada (IIA).
En las pruebas de integración aisladas, el área de impacto principal afecta al repository adapter. En este caso, el snapshot de la BD pasa a ser un área secundaria ya que no es la BD “real”, por lo que tampoco probamos su configuración.
Después de ver las áreas de impacto de los dos tipos de pruebas, podemos valorar que el grado de confianza de las pruebas integradas de integración es mayor que el grado de confianza de su homónimo aislado.
Área de impacto en pruebas funcionales integradas y aisladas
En el caso de las pruebas funcionales tanto integradas como aisladas, es más complejo ver o diferenciar entre las áreas de impacto principales e irradiadas, esto es debido a que al comprobar una funcionalidad el MIA abarca casi todo este scope.
En las siguientes imágenes vamos a ver cúal es el área de impacto de una prueba que ataca una funcionalidad concreta, en el caso de una prueba funcional integrada y la misma de forma aislada.
El grado de confianza seguirá siendo mayor en la pruebas integradas, no obstante aislarlas nos dará ciertos beneficios como poder lanzarlas en un entorno local de desarrollo.
En el caso de la pruebas funcionales de soporte y exploratorias el área de impacto sería el mismo que las que hemos visto en las integradas ya que seguimos con una comunicación real con nuestra BD, servicios etc.
Área de impacto en pruebas de contrato
En el caso de las pruebas de contrato tenemos que valorar el área de impacto dependiendo de si son pruebas de proveedor o consumidor.
En el caso de las pruebas de proveedor el MIA se focalizará en los controladores, al mockear sus colaboradores no habrá áreas irradiadas. En el caso de las pruebas de consumidor el MIA afecta a la clase cliente (service adapter), pero en este caso la capa de dominio si se ve afectada por el IIA, ya que la clase cliente implementa clases de dominio.
Área de impacto en pruebas unitarias
En las pruebas unitarias el área de impacto principalmente se focaliza en la clase testeada en el caso de ser unit solitary tests. Por otro lado, en el caso de ser sociable unit test tendemos áreas de impacto irradiadas.
Podéis seguir este enlace para conocer los dos tipos de pruebas unitarias.
Comparando el grado de confianza entre tipos de prueba
Ahora que hemos visto lo que es el grado de confianza por cada tipo de prueba, vamos a ver el gráfico de dimensiones que comentábamos al principio del post. Mediremos:
- Grado de confianza, representado por círculos con más o menos radio, en base al grado de confianza.
Es importante destacar que el grado de confianza lo he valorado por la capacidad de impacto del tipo de prueba, por ejemplo, las pruebas unitarias pueden tener impacto en la mayor parte del código.
Al igual que en el caso de las pruebas aisladas funcionales frente a las funcionales o E2E de soporte, que tendrá un mayor grado de confianza debido a que lo normal es tener un mayor número de pruebas aisladas que pruebas integradas de soporte. - Ámbito (scope) de las pruebas, en el eje X. Se trata de comprobar una parte del código, una funcionalidad concreta o un E2E.
- Etapa (stage) de las pruebas, en el eje Y. Fase en la que se lanzan las pruebas en local durante el desarrollo, en el CI, o en fases de preproducción o producción.
CONCLUSIONES
El grado de confianza no debería darnos a elegir entre un tipo de prueba u otra, como vemos en el gráfico, cada prueba tiene un scope y un stage diferente, es por eso que son complementarias unas con otras. Por el contrario, sí nos puede ayudar en definir nuestra estrategia de testing.
Las pruebas aisladas deberían estar más presentes en las fases tempranas del desarrollo, de esta forma vamos a poder desarrollar de forma más fiable y destapar cuanto antes los bugs más críticos o bloqueantes.
Las pruebas integradas deberían ayudarnos a destapar aquellos errores que vengan por infraestructura o aquellos que no sean bloqueantes. Deberían ser pruebas de soporte que nos ayuden a obtener mayor información sobre el estado de nuestra aplicación.
No obstante cómo he dicho, la estrategia de testing que sigamos debe estar alineada con el contexto situacional. La estrategia puede y debe ir pivotando y creciendo de forma progresiva, adaptándose poco a poco.
POSTS DE LA SERIE
1/3 Dimensiones entre pruebas aisladas e integradas. Grado de confianza.
2/3 Dimensiones entre pruebas aisladas e integradas. Tiempo de test.
3/3 Dimensiones entre pruebas aisladas e integradas. Test flakiness.