¿Cómo critican las pruebas de integración al diseño?

Estoy leyendo en el blog de JB Rainsberger sobre pruebas integradas y me pregunto de qué manera una prueba de integración es más dura con nuestro diseño.

Escribimos más pruebas integradas, que son más grandes y no critican nuestro diseño con tanta dureza como lo hacen los microtests.

Las microtestas pueden ayudar a llevar a un buen diseño . Al escribir buenas pruebas pequeñas, está probando deliberadamente una pequeña cantidad de código y rellenando sus huecos con objetos simulados . Esto conduce a un bajo acoplamiento (las cosas no dependen unas de otras) y una alta cohesión (las cosas que pertenecen juntas permanecen juntas). De esa manera, cuando regresa y hace cambios, es fácil encontrar qué es responsable de lo que está buscando y es menos probable que rompa las cosas al hacer el cambio. Esto no resolverá todo su diseño, pero puede ayudar.

En este contexto, JB Rainsberger señala que si tiene dificultades para escribir una prueba unitaria, es probable que tenga un problema con su diseño que esté causando la dificultad y, por lo tanto, las pruebas están criticando el diseño implícitamente. Él postula que esto es algo bueno, porque sin las pequeñas pruebas ayudan a mantener su arquitectura en línea, es fácil alejarse de los buenos patrones de diseño, que las pruebas integradas no capturarán.

Actualización : como señala Rainsberger a continuación, no tenía la intención de que los microtests fueran sinónimos de pruebas unitarias. También proporcionó una respuesta detallada que puede darle una visión más profunda de exactamente lo que estaba comunicando.

La versión extremadamente corta: las pruebas más pequeñas, debido a que ejecutan partes más pequeñas del sistema, limitan naturalmente lo que los programadores pueden escribir, por lo que esto crea una oportunidad para comentarios más precisos (más fáciles de notar / más difíciles de ignorar). Permítanme agregar que esto no necesariamente conduce a un mejor diseño, sino que crea la oportunidad de notar los riesgos de diseño antes.

Primero, para aclarar, cuando digo "microtest" quiero decir "una pequeña prueba" y nada más. Uso este término porque no me refiero a "prueba unitaria": no quiero involucrarme en debates sobre lo que constituye una "unidad". No me importa (al menos no aquí / ahora). Dos personas probablemente estarán de acuerdo más fácilmente en "pequeño" que en "unidad", por lo que gradualmente decidí adoptar "microtest" como un término estándar emergente para esta idea.

Las pruebas más grandes, es decir, las pruebas que ejecutan partes más grandes del sistema en su parte de "acción", tienden a no criticar el diseño de manera tan clara ni tan completa como las pruebas más pequeñas. Imagine el conjunto de todas las bases de código que podrían pasar un grupo dado de pruebas, lo que significa que podría reorganizar el código y aún así pasaría esas pruebas. Para pruebas más grandes, este conjunto es más grande; para pruebas más pequeñas, este conjunto es más pequeño. Dicho de otra manera, las pruebas más pequeñas limitan más el diseño, por lo que menos diseños pueden hacer que pasen. De esta manera, los microtestas pueden criticar más el diseño.

Digo "con más dureza" para conjurar la imagen de un amigo que te dice directamente lo que no quieres escuchar, pero que necesitas escuchar, y que te grita para que expreses urgencia de una manera que otras personas puedan no sentirse cómodas. obra. Las pruebas integradas, por otro lado, permanecen silenciosas y solo sugieren problemas, principalmente cuando ya no tienes tiempo ni energía para abordarlos. Las pruebas integradas hacen que sea demasiado fácil barrer los problemas de diseño debajo de la alfombra.

Con pruebas más grandes (como las pruebas integradas), los programadores tienden a meterse en problemas por descuido: tienen suficiente libertad para escribir código enredado que de alguna manera pasa las pruebas, pero su comprensión del código se desvanece rápidamente en el momento en que pasan a la siguiente tarea. , y otros tienen dificultades innecesarias para leer el diseño enredado. Aquí radica el riesgo de depender de pruebas integradas. Con pruebas más pequeñas (como microtestas), los programadores tienden a meterse en problemas debido a una especificación excesiva: restringen las pruebas al agregar detalles irrelevantes, generalmente copiando / pegando de la prueba anterior, y al hacerlo se pintan relativamente rápido en una esquina Buenas noticias: Me resulta mucho más fácil y seguro eliminar detalles extraños de las pruebas varias horas o días después de escribirlos que encontrar el código de producción enredado meses o años después de escribirlo. A medida que avanzan los errores, la especificación excesiva hace que el daño sea cada vez más evidente y más rápido, y el programador de alertas ve antes que necesitan arreglar las cosas. Considero que esto es una fortaleza: noto problemas antes y los soluciono antes de que esos problemas estrangulen nuestra capacidad de agregar funciones.

Quiere decir que un buen diseño de software está mejor informado por pruebas unitarias que por pruebas de integración.

Este es el por qué. Escribir pruebas unitarias te obliga a escribir código que sea comprobable por unidades. El código de prueba unitaria tiende a ser un mejor diseño que el código que no tiene pruebas unitarias.

Las pruebas de integración no informan su código de la misma manera porque solo está probando la capa externa de su software, no las interfaces internas que conectan su software.