En primer lugar, TDD no le obliga estrictamente a escribir el código SOLID. Podrías hacer TDD y crear un gran lío si quisieras.
Por supuesto, conocer los principios SÓLIDOS es útil, porque de lo contrario, es posible que simplemente no tenga una buena respuesta a muchos de sus problemas y, por lo tanto, escriba un código incorrecto acompañado de pruebas incorrectas.
Si ya conoce los principios de SOLID, TDD lo alentará a que piense en ellos y los use activamente.
Dicho esto, no necesariamente cubre todas las letras en SÓLIDO , pero lo alienta y lo promueve a que escriba, al menos en parte, un código SÓLIDO, porque tiene las consecuencias de no hacerlo. Inmediatamente visible y molesto.
Por ejemplo:
- Necesitas escribir código desacoplado para que puedas burlarte de lo que necesitas. Esto es compatible con el Principio de inversión de dependencia .
- Necesita escribir pruebas que sean claras y cortas para que no tenga que cambiar demasiado en las pruebas (que pueden convertirse en una fuente importante de ruido de código si se hace de otra manera). Esto es compatible con el principio de responsabilidad única .
- Esto puede discutirse, pero el Principio de Segregación de la Interfaz permite que las clases dependan de interfaces más ligeras que hacen que el simulacro sea más fácil de seguir y entender, porque no tiene que preguntar "¿Por qué no ¿estos 5 métodos se burlaron también? ", o lo que es más importante, no tienes mucha elección a la hora de decidir qué método simular. Esto es bueno cuando realmente no quiere revisar todo el código de la clase antes de probarlo, y simplemente use prueba y error para obtener una comprensión básica de cómo funciona.
Adherirse al principio Abierto / Cerrado puede ayudar a las pruebas que se escriben después de el código, porque generalmente le permite anular las llamadas de servicio externas en las clases de prueba que se derivan de las clases en prueba. En TDD creo que esto no es tan requerido como otros principios, pero puedo estar equivocado.
Adherirse a la regla de sustitución de Liskov es excelente si desea minimizar los cambios para que su clase reciba una instancia no compatible que simplemente implementa la misma interfaz de tipo estático, pero no es probable que ocurra en los casos de prueba adecuados porque por lo general, no pasará ninguna clase bajo prueba de las implementaciones de sus dependencias en el mundo real.
Lo más importante es que los principios de SOLID se crearon para alentarlo a escribir un código más limpio, más comprensible y fácil de mantener, y también lo fue el 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 retroalimentación inmediata, API y corrección), puede preocuparse menos por los principios de SOLID, en general.