¿Qué significa "DAMP not DRY" cuando se habla de pruebas unitarias?

Escuché a alguien decir que las pruebas unitarias (por ejemplo, nUnit, jUnit, xUnit) deberían ser

DAMP 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, sino que equilibran dos aspectos diferentes de la capacidad de mantenimiento 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, tienes que leerlo. Considere por un momento cuánto tiempo pasa leyendo el código. Es mucho. DAMP aumenta la capacidad de mantenimiento al reducir el tiempo necesario para leer y comprender el código.

DRY (no se repita) promueve la ortogonalidad del código.

Eliminar la duplicación asegura que cada concepto en el sistema tenga una única representación autorizada en el código. Un cambio en un solo concepto de negocio da como resultado un solo cambio en el código. DRY aumenta la capacidad de mantenimiento 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 duplicación inherente porque están probando lo mismo una y otra vez, solo 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 está aislada solo de 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 duplicación reduce la legibilidad de las pruebas. Los detalles que se duplicaron previamente en cada prueba ahora están ocultos en algún nuevo método o clase. Para obtener una imagen completa de la prueba, ahora tiene que 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 cómo 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 puede inclinar la balanza a su favor.

DAMP - Frases descriptivas y significativas.

"DAMP not DRY" valora la legibilidad sobre la reutilización del código. La idea de DAMP not DRY en 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 el código duplicado más tolerable en las pruebas unitarias? para alguna discusión sobre los méritos de este punto de vista.

Pudo haber sido acuñado por Jay Fields , en relación con los lenguajes específicos de dominio.

"SECO" es "No te repitas"

Este es un término que se usa para decirle a las personas que escriban código que sea reutilizable, para que no termines escribiendo código similar una y otra vez.

"DAMP" es "Frases descriptivas y significativas".

Este término tiene la intención de decirle que escriba un código que pueda entender fácilmente alguien que lo esté mirando. Si sigue este principio, tendrá nombres largos y descriptivos de variables y funciones, etc.

Damp = 'Frases descriptivas y significativas' - sus pruebas unitarias deberían poder 'leerse':

La legibilidad es más importante que evitar el código redundante.

Del artículo:

DAMP significa "frases descriptivas y significativas" y es lo opuesto a DRY, no en el sentido de que dice "todo debería verse como un montón de basura y ser imposible de leer", ya que la legibilidad es más importante que evitar el código redundante.

¿Qué significa esto y dónde usarlo?

DAMP se aplica principalmente al escribir código de prueba. El código de prueba debe ser muy fácil de entender hasta el punto de que es aceptable cierta redundancia.

DAMP significa "frases descriptivas y significativas" y es lo opuesto a DRY, no en el sentido de que dice "todo debería verse como un montón de basura y ser imposible de leer", ya que la legibilidad es más importante que evitar el código redundante.

http://codeshelter.wordpress.com/2011/04/07/dry-and-damp-principles-when-developing-and-unit-testing/

Ya hay varias respuestas aquí, pero quería agregar otra ya que no pensé que necesariamente lo explicaran tan bien como pudieran.

La idea de DRY (no se repita) es que en el código de su aplicación desea evitar el código redundante o repetitivo. Si tiene algo que su código necesita hacer varias veces, debe tener una función o clase para ello, en lugar de repetir un código similar en varios lugares.

Este es un concepto de programación bastante conocido.

DAMP (Frases descriptivas y significativas) es para sus pruebas unitarias. La idea aquí es que los nombres de sus métodos de prueba de unidad deben ser largos y descriptivos, oraciones cortas que describan lo que está probando.

p.ej: testWhenIAddOneAndOneIShouldGetTwo() { .... }

Cuando lee un nombre de método DAMP como este, debe comprender exactamente lo que el escritor de prueba estaba tratando de lograr, sin siquiera tener que leer el código de prueba (aunque el código de prueba también puede seguir este concepto también, por supuesto, con nombres de variables verbales, etc)

Esto es posible porque un método de prueba unitaria tiene una entrada muy específica y una salida esperada, por lo que el principio DAMP funciona bien para ellos. Es poco probable que los métodos en su código de aplicación principal sean lo suficientemente específicos como para garantizar nombres como este, especialmente si lo ha escrito teniendo en cuenta el principio DRY.

DAMP y DRY no se contradicen entre sí: cubren diferentes aspectos de cómo se escribe su código, pero no obstante, generalmente no se usan juntos porque los métodos escritos con el principio DRY en mente serían de propósito general y es poco probable que sean adecuados a nombre de método altamente específico. Por lo tanto, en general, como se explicó anteriormente, su código de aplicación debe estar SECO y su código de prueba de unidad DAMP.

Espero que eso ayude a explicarlo un poco mejor.

Estoy de acuerdo con Chris Edwards en que debes lograr un equilibrio entre los dos. Otra cosa a tener en cuenta es que si, en un intento de eliminar la duplicación, terminas agregando una gran cantidad de estructura adicional en el código de prueba de tu unidad (es decir, al llevar DRY a los extremos), corres el riesgo de introducir errores allí. En tal situación, tendría que hacer una prueba unitaria de sus pruebas unitarias o dejar fragmentos de estructura sin probar.

No deseo duplicar el esfuerzo aquí, pero puede tener pruebas que son DAMP pero tienen el beneficio de DRY. Por otro lado, las pruebas DRY no satisfarán las pruebas DAMP en algunos casos.

He blogueado sobre DRY vs DAMP que incluye algunos ejemplos.

Ningún enfoque debería ser su única solución, a veces DAMP es excesivo, otras veces una muy buena adición.

Como regla general, debe aplicar la regla de tres. Si ve la duplicación por tercera vez, puede valer la pena estudiar cómo escribir pruebas de estilo DAMP, pero aun así no toda la duplicación es mala . El contexto importa.