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.