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

15

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?

unit-testing tdd solid SiberianGuy
fuente
1
TDD se trata principalmente de obligar a los desarrolladores a escribir pruebas. Entonces, si dices que escribir pruebas unitarias te hace escribir código SOLID, supongo que eso dice que TDD te obliga a escribir código SOLID. Sin embargo, esto se basa solo en lo que ha dicho y no refleja con precisión mi opinión, que puede ver en mi respuesta.
Yam Marcovic
1
Yam: No estaré de acuerdo, TDD no se trata de escribir pruebas unitarias. TDD se trata de llegar a una solución mínimamente compleja y correcta para el problema en cuestión. Las pruebas son solo un subproducto del procedimiento
Amit Wadhwa
TDD, por definición, se trata de escribir pruebas antes del código. Teóricamente, puede crear una solución mínimamente compleja y correcta incluso sin pruebas. Las pruebas simplemente le dan retroalimentación instantánea y conciencia de regresión. Dado que todavía es posible crear una solución demasiado compleja con pruebas, TDD no se trata de crear soluciones mínimamente complejas per se. Es lo contrario de lo que has dicho. Las soluciones elegantes son un subproducto del procedimiento, no al revés.
Yam Marcovic el

Respuestas:

24

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.

Ñame Marcovic
fuente
Además, a menos que sigas Open / closed y Liskov sustitución, tus simulacros se romperán más adelante. Entonces, incluso si TDD podría no ayudarlo a aplicar OCP y LSP, las pruebas creadas le informarán cuando lo rompa. Más un efecto de las pruebas en general, pero aún vale la pena mencionarlo.
Jonas Schubert Erlandsson
9

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.

dietbuddha
fuente
2

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.

Heath Lilley
fuente