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.

Este jueves 9 de marzo estaré participando del ciclo de charlas técnicas organizado por la gente de Abstracta. En dicho espacio hablaré sobre mi visión actual del testing en general y del rol de tester en particular. La charla está pensada como una continuidad/profundización de la charla que dí en la QualitySense Conf en diciembre 2022 (video disponible aquí) y resume lo que actualmente enseño en la universidad.

Algunos puntos centrales de la charla:

• Parte del testing lo deben hacer los desarrolladores.
• Los testers deben trabajar muy cerca de la gente de negocio.
• Los casos de pruebas deben generarse temprano en la iteración, incluso algunos casos de prueba deberían estar claros al finalizar la reunión de planificación de la iteración.
• La gran mayoría del testing debe estar automatizado.
• La ejecución de la mayoría de los test debe poder ejecutarse sin necesidad de utilizar un ambiente particular.
• Testear algunas cuestiones en producción es válido, pero ello requiere planificación de cara a poder contemplarlo a nivel de desarrollo e infraestructura.

Varios de los puntos anteriores impactan directamente en las tareas y habilidades del tester y sé también que algunos pueden resultar polémicos. Esto es una buena excusa para sumarse la charla, es gratuita pero require registración.

Del 5 al 10 de diciembre voy a estar en Montevideo para participar de estos dos eventos.

El Workshop on Performance and Reliability (WOPR) es una evento cerrado que se accede por postulación/invitación y que tiene ~25 cupos por edición. Hay un grupo de organizadores que asegura la continuidad del evento (esta será la edición 29), luego hay una empresa del rubro (performance & reliability) que «hostea» el evento y se encarga de las cuestiones logísticas. Los interesados en participar envían una propuesta, la misma es evaluada por los organizadores y en base a eso se envían las invitaciones. En esta edición la empresa host es Abstracta, pueden encontrar más información al respecto del WORP en este post de Federico Toledo.

A continuación del WORP y organizado también por Abstracta, tendrá lugar el viernes 9 de diciembre en la torre Antel, la Quality Sense Conf. Esta conferencia será gratuita y en formato híbrido. En este contexto voy a estar dando una charla que he titulado «Testing 3.0» :

Las estrategias de testing y el rol de tester ha ido cambiando a lo largo del tiempo influenciado, entre otras cuestiones, por los avances tecnológicos y metodológicos. Desde los procesos «cascadosos» y las aplicaciones mainframes, pasando por los métodos ágiles, las aplicaciones de escritorio, a las aplicaciones web, mobile y el auge de DevOps. Los desafíos que enfrenta la industria del software en la actualidad han generado importantes desafíos y oportunidades para quienes trabajan en cuestiones de testing y calidad en general. En esta charla veremos algunas de esas oportunidades y cómo prepararnos para sacarle el mayor provecho.