¿El desarrollo basado en pruebas me obliga a seguir SOLID?

Escucho mucho de los profesionales de TDD que una de las ventajas de TDD es que obliga a los desarrolladores a seguir los principios SÓLIDOS (responsabilidad única, abierto-cerrado, sustitución de Liskov, segregación de interfaz e inversión de dependencia). Pero en cuanto a mí, es suficiente escribir algunas pruebas (prueba unitaria principalmente) para comprender que es importante seguir SOLID (y así crear una arquitectura comprobable).

¿TDD obliga a los desarrolladores a seguir SOLID más activamente que simplemente escribir pruebas unitarias?

En primer lugar, TDD no lo obliga estrictamente a escribir código SOLIDO. Podrías hacer TDD y crear un gran desastre si quisieras.

Por supuesto, conocer los principios SÓLIDOS ayuda, porque de lo contrario puede terminar sin tener una buena respuesta a muchos de sus problemas y, por lo tanto, escribir un código incorrecto acompañado de malas pruebas.

Si ya conoce los principios de SOLID, TDD lo alentará a pensar en ellos y usarlos activamente.

Dicho esto, no necesariamente cubre todas las letras en SOLID , pero lo alienta y lo promueve a que escriba código al menos parcialmente SOLID, porque hace que las consecuencias de no hacerlo sean inmediatamente visibles y molestas.

Por ejemplo:

1. Necesita escribir código desacoplado para que pueda burlarse de lo que necesita. Esto apoya el principio de inversión de dependencia .
2. Debe escribir pruebas que sean claras y cortas para que no tenga que cambiar demasiado en las pruebas (lo que puede convertirse en una gran fuente de ruido de código si se hace de otra manera). Esto apoya el Principio de Responsabilidad Única .
3. Esto puede discutirse, pero el Principio de segregación de interfaz permite que las clases dependan de interfaces más ligeras que hacen que la burla sea más fácil de seguir y comprender, porque no tiene que preguntarse "¿Por qué no se burlaron estos 5 métodos también?", O aún más importante, no tienes muchas opciones al decidir qué método burlarte. Esto es bueno cuando realmente no desea repasar todo el código de la clase antes de probarlo, y solo usa prueba y error para obtener una comprensión básica de cómo funciona.

Cumplir con el principio Abierto / Cerrado puede ayudar a las pruebas que se escriben después del código, porque generalmente le permite anular las llamadas de servicio externas en las clases de prueba que se derivan de las clases bajo prueba. En TDD, creo que esto no es tan obligatorio como otros principios, pero puedo estar equivocado.

Cumplir con la regla de sustitución de Liskov es excelente si desea minimizar los cambios para que su clase reciba una instancia no admitida que simplemente implemente la misma interfaz estáticamente tipada, pero no es probable que suceda en los casos de prueba adecuados porque generalmente no pasará ninguna clase bajo prueba de las implementaciones del mundo real de sus dependencias.

Lo más importante, los principios SÓLIDOS se hicieron para alentarlo a escribir un código más limpio, más comprensible y fácil de mantener, y también lo fue TDD. Entonces, si hace TDD correctamente y presta atención a cómo se ven su código y sus pruebas (y no es tan difícil porque obtiene comentarios inmediatos, API y corrección), puede preocuparse menos por los principios SOLID, en general.

No

TDD puede facilitar el seguimiento de buenas prácticas debido a la refactorización continua, pero no obliga a seguir ningún principio. Todo lo que hace es asegurarse de que se prueba el código que escribe. Puede seguir los principios que desee al escribir código para satisfacer la prueba; o no hay principios en absoluto.

Mi comprensión de los Principios SÓLIDOS se expandió en un orden de magnitud cuando comencé a hacer TDD. Tan pronto como comencé a pensar en cómo burlarme de las dependencias, me di cuenta de que prácticamente todos los componentes de la base de código tenían una implementación alternativa potencial. Y cuánto más fácil es probar una API pública simple.

También proporcionó una comprensión mucho más fuerte de la mayoría de los patrones de diseño. Especialmente el patrón de estrategia.

Sí : TDD es principalmente una buena técnica de diseño (y solo secundaria una técnica de prueba). Ayuda mucho a lograr los principios sólidos, aunque todavía son posibles ejemplos (patológicos) de TDD con muchos olores de código.

La conexión entre TDD y los principios sólidos se disputa (con la conclusión anterior) en este gran podcast de hanselminute llamado "Test Driven Development is Design - The Last Word on TDD" .