Tengo la sensación que este tipo de pruebas no es muy conocido y al mismo tiempo es un tipo de prueba que me parece fundamental para poder trabajar en un esquema de entrega continua. Paso a explicar.

En la actualidad es muy común que una aplicación tenga dependencias que no están bajo nuestro control, típicamente alguna API de un servicio externo. Ejemplos típicos podrían incluir un servicio de pagos o un proveedor de información climática. Esos servicios externos pueden ser parte de nuestra misma organización o no, pero en ambos casos el punto en común es que no tenemos control sobre ellos.

Muchas veces esta dependencia resulta un impedimento para poder testear nuestra aplicación y aquí está el punto clave a la hora de querer implementar una estrategia de entrega continua. Si queremos trabajar en un esquema de entrega continua tenemos que poder testear (casi) todo nuestro código sin depender de la disponibilidad del servicio externo.

En una prueba end-to-end testeamos todo nuestro código incluida la interacción con las dependencias externas.

En una prueba end-to-EDGE testeamos todo nuestro código sin «tocar» las dependencias externas. Esto lo hacemos utilizando «un doble de prueba» de la dependencia. Una forma de implementar esto es usando una herramienta tipo Wiremock.

Cabe destacar aquí, que en estos tests end-to-edge, nuestra aplicación «no sabe» que está interactuando con un doble de prueba, pues lo único que hace es tirar un request sin saber quién está del otro lado. Al mismo tiempo como ese doble de prueba está bajo nuestro control, tenemos la posibilidad de generar respuestas que nos permitan ejercitar distintos escenarios, algo que muchas veces no es posible con las pruebas end-to-end, pues en la prueba end-to-end no tenemos control sobre esa api/depedencia externa. ¿Cómo haríamos para probar el comportamiento de nuestra aplicación cuando esa api/dependencia externa falla? ¿Llamamos al dueño de la api/dependencia externa y le decimos que la apague un rato para poder probar el escenario de error? No parece factible, lo que debemos hacer no es una prueba end-to-end, sino una prueba end-to-edge que utilice nuestro doble de prueba en lugar de la api/dependencia externa real.

Una última consideración, si vamos a hacer pruebas end-to-edge utilizando un doble de prueba de la api/dependencia externa, debemos entonces también tener alguna prueba de integración que verifique la correcta interacción con la api/dependencia externa, pues sin eso corremos el riesgo de que la api/dependencia externa cambie y nosotros no nos enteremos pues confiamos en la corrección de nuestro doble de prueba que podría quedar desactualizado. Esas pruebas de integración con la api/dependencia externa no es necesario que sean pruebas end-to-end, sino que basta con que sean pruebas puntuales del componente/conector que encapsula la interacción con esa api/dependencia externa. Finalmente es importante que esas pruebas de integración se ejecuten periódicamente aún cuando no haya cambios en nuestro código, pues puede que se produzcan cambios en el api/dependencia externa y no nos avisen.

Para intentar clarificar varias de estas ideas he grabado una par de videos explicando esto con gráficos y código.