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.

En mi opinión no hay una definición única sobre qué es una prueba de integración. En términos muy generales suele asumirse que prueba de integración verifica la integración de dos (o más) componentes. La cuestión (o diferencia) radica en qué son esos componentes.

Algunos (¿la mayoría?) considera que esos dos componentes son componentes de nuestra propia autoría, por ejemplo: tengo dos clases desarrolladas por mi con algún tipo de dependencia entre ellas, claseA y claseB, entonces mi prueba de integración busca verificar la correcta interacción de esas dos clases entre sí.

Otros, donde me cuento yo, pensamos más en línea con la propuesta de Freeman. En este caso uno de los componentes en la prueba de integración no está bajo nuestro control, o sea: no lo desarrollamos nosotros. Esto hace que el foco de la prueba de integración pase por verificar la interacción del código que está bajo nuestro control con código que no lo está. Un caso típico es cuando nuestra aplicación debe interactuar con una aplicación/servicio/api externo como ser una API REST desarrollada por otro equipo/organización. En este caso, no tiene ningun sentido utiliza mocks (dobles de prueba) porque justamente lo que quiero verificar es la interacción con ese sistema externo, entonces de nada sirve reemplazar ese sistema externo con un doble de prueba.