Mientras aplaudimos el foco en las pruebas automatizadas, seguimos viendo numerosas organizaciones que invierten excesivamente en lo que creemos son ineficaces Amplias pruebas de integración. Como el término “prueba de integración” es ambiguo, tomamos la clasificación amplia de la entrada bliki de Martin Fowler sobre este tema, haciendo referencia a una prueba que requiere versiones en produccion de todas las dependencias en tiempo de ejecución. Tales pruebas son obviamente costosas, ya que requieren entornos de prueba con todas las funcionalidades, con la infraestructura necesaria, datos y servicios. Administrar las versiones correctas de dichas dependencias requiere de un trabajo de coordinación importante, que tiende a ralentizar los ciclos de lanzamiento. Para finalizar, las pruebas por sí mismas son comúnmente frágiles y de poca ayuda. Por ejemplo, necesitamos mucho esfuerzo para determinar si una prueba falló por el código nuevo, la versión incorrecta de dependencias o por el entorno, además, el mensaje de error rara vez ayuda a identificar la fuente del error. Estas críticas no significan que nos opongamos a las pruebas automatizadas de integración “caja negra” en general, más bien, encontramos que un enfoque más útil es aquel que balancea las necesidades de confianza con la frecuencia de lanzamiento. Esto se puede hacer en dos etapas: primero validando el comportamiento del sistema bajo prueba asumiendo cierto conjunto de respuestas de las dependencias en tiempo de ejecución y luego, validando dichas suposiciones. La primera etapa usa la virtualización de servicios para crear pruebas dobles de dependencias en tiempo de ejecución y validar el comportamiento del sistema bajo la prueba. Eso simplifica lo que afecta a la gestión de los datos de prueba y permite tests deterministas. La segunda etapa utiliza pruebas de contrato para validar las suposiciones del entorno con dependencias reales.
