¿Qué significa "HÚMEDO, no SECO" cuando se habla de pruebas unitarias?
Escuché a alguien decir que las pruebas unitarias (por ejemplo, nUnit, jUnit, xUnit) deberían ser
HÚMEDO no SECO
(Por ejemplo, las pruebas unitarias deben contener "código húmedo", no "código seco")
De qué están hablando?
Es un equilibrio, no una contradicción.
DAMP y DRY no son contradictorios, más bien equilibran dos aspectos diferentes de la mantenibilidad de un código . El código mantenible (código que es fácil de cambiar) es el objetivo final aquí.
DAMP (frases descriptivas y significativas) promueve la legibilidad del código.
Para mantener el código, primero debe comprender el código. Para entenderlo hay que leerlo. Considere por un momento cuánto tiempo dedica a leer código. Es mucho. DAMP aumenta la capacidad de mantenimiento al reducir el tiempo necesario para leer y comprender el código.
DRY (No te repitas) promueve la ortogonalidad del código.
Eliminar la duplicación garantiza que cada concepto del sistema tenga una única representación autorizada en el código. Un cambio a un único concepto de negocio da como resultado un único cambio en el código. DRY aumenta la mantenibilidad al aislar el cambio (riesgo) solo en aquellas partes del sistema que deben cambiar.
Entonces, ¿por qué la duplicación es más aceptable en las pruebas?
Las pruebas a menudo contienen duplicaciones inherentes porque prueban lo mismo una y otra vez, solo que con valores de entrada o código de configuración ligeramente diferentes. Sin embargo, a diferencia del código de producción, esta duplicación generalmente se limita solo a los escenarios dentro de un único dispositivo/archivo de prueba. Debido a esto, la duplicación es mínima y obvia, lo que significa que representa menos riesgo para el proyecto que otros tipos de duplicación.
Además, eliminar este tipo de duplicaciones reduce la legibilidad de las pruebas. Los detalles que antes se duplicaban en cada prueba ahora están ocultos en algún método o clase nueva. Para obtener una imagen completa de la prueba, ahora debes volver a juntar mentalmente todas estas piezas.
Por lo tanto, dado que la duplicación del código de prueba a menudo conlleva menos riesgos y promueve la legibilidad, es fácil ver por qué se considera aceptable.
Como principio, favorezca DRY en el código de producción, favorezca DAMP en el código de prueba. Si bien ambos son igualmente importantes, con un poco de sabiduría puedes inclinar la balanza a tu favor.
HÚMEDO: frases descriptivas y significativas.
"DAMP not DRY" valora la legibilidad sobre la reutilización del código. La idea de DAMP not DRY en los casos de prueba es que las pruebas deben ser fáciles de entender, incluso si eso significa que los casos de prueba a veces tienen código repetido.
Consulte también ¿Es más tolerable el código duplicado en las pruebas unitarias? para una discusión sobre los méritos de este punto de vista.
Pudo haber sido acuñado por Jay Fields , en relación a los lenguajes específicos de dominio.
"SECO" es "No te repitas"
Este es un término que se utiliza para decirle a la gente que escriba código que sea reutilizable, de modo que no termine escribiendo código similar una y otra vez.
"DAMP" significa "frases descriptivas y significativas".
Este término pretende indicarle que escriba código que pueda ser entendido fácilmente por alguien que lo esté mirando. Si sigue este principio, tendrá nombres de funciones y variables largos y descriptivos, etc.
