unit testing - tools - ¿Qué significa "DAMP no SECO" cuando se habla de pruebas unitarias?
unit testing php (8)
DAMP - Frases descriptivas y significativas.
Los valores de "DAMP not DRY" son legibles en la reutilización del código. La idea de DAMP no SECA 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ódigos repetidos.
Consulte también ¿Es el código duplicado más tolerable en las pruebas unitarias? para una discusión sobre los méritos de este punto de vista.
Puede haber sido acuñado por DAMP , en relación con los lenguajes específicos del dominio.
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 final (el 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 debes entender el código. Para entenderlo, hay que leerlo. Considera por un momento cuánto tiempo pasas 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 orthogonality del código.
La eliminación de la duplicación garantiza 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ódigos de configuración ligeramente diferentes. Sin embargo, a diferencia del código de producción, esta duplicación generalmente está aislada solo en los escenarios dentro de un único archivo / dispositivo de prueba. Debido a esto, la duplicación es mínima y obvia, lo que significa que representa un riesgo menor para el proyecto que otros tipos de duplicación.
Además, la eliminación de 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 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 cómo se considera aceptable.
Como principio, favorece DRY en el código de producción, favorece DAMP en el código de prueba. Si bien ambos son igual de importantes, con un poco de sabiduría puedes inclinar la balanza a tu favor.
"SECO" es "No te repitas"
Este es un término que se usa para decirle a la gente que escriba un código que sea reutilizable, para que no termine de escribir un código similar una y otra vez.
"DAMP" es "Frases descriptivas y significativas".
El objetivo de este término es indicarle que escriba un código que pueda entender fácilmente alguien que lo esté viendo. Si está siguiendo este principio, tendrá variables largas y descriptivas, nombres de funciones, etc.
DAMP significa “frases descriptivas y significativas” y es lo opuesto a DRY, no en el sentido de que diga “todo debe parecer un basurero y ser imposible de leer”, ya que la legibilidad es más importante que evitar el código redundante.
Estoy de acuerdo con Chris Edwards en que necesitas encontrar un equilibrio entre los dos. Otra cosa a tener en cuenta es que si, en un intento de eliminar la duplicación, termina agregando una gran cantidad de estructura adicional en el código de prueba de su unidad (es decir, cuando lleva DRY a extremos), corre el riesgo de introducir errores allí. En tal situación, tendría que realizar una prueba unitaria de las pruebas unitarias o dejar los bits de la estructura sin probar.
Humedad = ''Frases descriptivas y significativas'': sus pruebas unitarias deben poder ser ''leídas'':
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 diga “todo debe parecer un basurero 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 el código de prueba. El código de prueba debe ser muy fácil de entender hasta el punto de que cierta redundancia es aceptable.
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 satisfacen las pruebas DAMP en algunos casos.
He blogeado sobre DRY vs DAMP que incluye algunos ejemplos.
Ninguno de los dos enfoques debe ser su única solución, a veces el DAMP es una exageración, otras veces una muy buena adición.
Como regla general debes aplicar la regla de tres. Si ve la duplicación por tercera vez, puede valer la pena estudiar las pruebas de estilo DAMP, pero incluso entonces no toda la duplicación es mala . El contexto importa.
Ya hay varias respuestas aquí, pero quería agregar otra ya que no creía que necesariamente lo explicaran tan bien como podrían.
La idea de DRY (no se repita) es que en su código de aplicación desea evitar el código redundante o reptetivo. Si tienes algo que tu código necesita hacer varias veces, debes 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 de unidad. 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á evaluando.
por ejemplo: testWhenIAddOneAndOneIShouldGetTwo() { .... }
Cuando lees un nombre de método DAMP como este, debes entender exactamente lo que el escritor de prueba estaba tratando de lograr, sin tener que leer el código de prueba (aunque el código de prueba también puede seguir este concepto, por supuesto, con nombres de variables con palabras, etc).
Esto es posible porque un método de prueba de unidad 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 para justificar 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, sin embargo, no suelen usarse juntos porque los métodos escritos con el principio DRY en mente serían de propósito general y probablemente no serían adecuados al nombre del método altamente específico. En general, por lo tanto, como se explicó anteriormente, el código de su aplicación debe estar SECO y el código de prueba de su unidad DAMP.
Espero que eso ayude a explicarlo un poco mejor.