Cosa significa "DAMP not DRY" quando si parla di unit test?

Ho sentito qualcuno dire che dovrebbero essere test unitari (es. NUnit, jUnit, xUnit)

UMIDO non ASCIUTTO

(Ad esempio, i test unitari dovrebbero contenere "codice umidità" e non "codice secco")

Di cosa stanno parlando?

È un equilibrio, non una contraddizione

DAMP e DRY non sono contraddittori, ma bilanciano due diversi aspetti della manutenibilità di un codice . Il codice mantenibile (codice facile da modificare) è l'obiettivo finale qui.

DAMP (Frasi descrittive e significative) promuove la leggibilità del codice.

Per mantenere il codice, devi prima capire il codice. Per capirlo, devi leggerlo. Considera per un momento quanto tempo passi a leggere il codice. È molto. DAMP aumenta la manutenibilità riducendo il tempo necessario per leggere e comprendere il codice.

DRY (non ripeterti) promuove l' ortogonalità del codice.

La rimozione della duplicazione garantisce che ogni concetto nel sistema abbia una singola rappresentazione autorevole nel codice. Una modifica a un singolo concetto aziendale comporta una singola modifica al codice. DRY aumenta la manutenibilità isolando il cambiamento (rischio) solo per le parti del sistema che devono cambiare.

Quindi, perché la duplicazione è più accettabile nei test?

I test contengono spesso duplicazioni intrinseche perché stanno testando la stessa cosa più e più volte, solo con valori di input o codice di configurazione leggermente diversi. Tuttavia, a differenza del codice di produzione, questa duplicazione è generalmente isolata solo dagli scenari all'interno di un singolo dispositivo / file di test. Per questo motivo, la duplicazione è minima e ovvia, il che significa che comporta meno rischi per il progetto rispetto ad altri tipi di duplicazione.

Inoltre, la rimozione di questo tipo di duplicazione riduce la leggibilità dei test. I dettagli precedentemente duplicati in ciascun test sono ora nascosti in alcuni nuovi metodi o classi. Per avere un quadro completo del test, ora devi ricomporre mentalmente tutti questi pezzi.

Pertanto, poiché la duplicazione del codice di prova comporta spesso meno rischi e promuove la leggibilità, è facile vedere come sia considerato accettabile.

In linea di principio, favorire il DRY nel codice di produzione, favorire il DAMP nel codice di prova. Mentre entrambi sono ugualmente importanti, con un po 'di saggezza puoi ribaltare l'equilibrio a tuo favore.

DAMP - Frasi descrittive e significative.

"DAMP non DRY" valorizza la leggibilità rispetto al riutilizzo del codice. L'idea di DAMP non DRY nei casi di test è che i test dovrebbero essere facili da capire, anche se ciò significa che i casi di test a volte hanno un codice ripetuto.

Vedi anche Il codice duplicato è più tollerabile nei test unitari? per qualche discussione sul merito di questo punto di vista.

Potrebbe essere stato coniato da Jay Fields , in relazione alle lingue specifiche del dominio.

"DRY" è "Non ripetere te stesso"

Questo è un termine che viene utilizzato per dire alle persone di scrivere codice riutilizzabile, in modo da non finire per scrivere codice simile più e più volte.

"DAMP" è "Frasi descrittive e significative".

Questo termine ha lo scopo di dirti di scrivere un codice che può essere facilmente compreso da qualcuno che lo sta guardando. Se segui questo principio, avrai nomi variabili e descrittivi lunghi e descrittivi, ecc.

Umido = "Frasi descrittive e significative": i test unitari dovrebbero poter essere "letti":

La leggibilità è più importante che evitare il codice ridondante.

Dall'articolo:

DAMP sta per "frasi descrittive e significative" ed è l'opposto di DRY, non nel senso che dice "tutto dovrebbe apparire come un mucchio di rifiuti ed essere impossibile da leggere", in quanto la leggibilità è più importante che evitare il codice ridondante.

Cosa significa questo e dove usarlo?

DAMP si applica principalmente quando si scrive il codice di prova. Il codice di prova dovrebbe essere molto semplice da capire al punto che una ridondanza è accettabile.

DAMP sta per "frasi descrittive e significative" ed è l'opposto di DRY, non nel senso che dice "tutto dovrebbe apparire come un mucchio di rifiuti ed essere impossibile da leggere", in quanto la leggibilità è più importante che evitare il codice ridondante.

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

Ci sono già diverse risposte qui, ma volevo aggiungerne un'altra perché non pensavo che lo spiegassero necessariamente nel miglior modo possibile.

L'idea di DRY (non ripeterti) è che nel tuo codice dell'applicazione desideri evitare il codice ridondante o ripetitivo. Se hai qualcosa che il tuo codice deve fare più volte, dovresti avere una funzione o una classe per esso, piuttosto che ripetere codice simile in più punti.

Questo è un concetto di programmazione abbastanza noto.

DAMP (Frasi descrittive e significative) è per i test unitari. L'idea qui è che i nomi dei metodi del test unitario siano lunghi e descrittivi, in pratica brevi frasi che descrivono ciò che si sta testando.

per esempio: testWhenIAddOneAndOneIShouldGetTwo() { .... }

Quando leggi un nome di metodo DAMP come questo, dovresti capire esattamente ciò che lo scrittore di test stava cercando di ottenere, senza nemmeno dover leggere il codice di test (anche se il codice di test può anche seguire questo concetto e ovviamente con nomi di parole prolissi, eccetera).

Ciò è possibile perché un metodo di test unitario ha input e output molto specifici, quindi il principio DAMP funziona bene per loro. È improbabile che i metodi nel codice dell'applicazione principale siano abbastanza specifici da giustificare nomi come questo, soprattutto se lo hai scritto tenendo presente il principio DRY.

DAMP e DRY non si contraddicono a vicenda - coprono diversi aspetti del modo in cui è scritto il codice - ma tuttavia non sono in genere usati insieme perché i metodi scritti tenendo presente il principio DRY sarebbero di uso generale e difficilmente adatti al nome del metodo altamente specifico. In generale, quindi, come spiegato sopra, il codice dell'applicazione deve essere DRY e il codice dell'unità test DAMP.

Spero che questo aiuti a spiegarlo un po 'meglio.

Sono d'accordo con Chris Edwards in quanto è necessario trovare un equilibrio tra i due. Un'altra cosa da notare è che se, nel tentativo di rimuovere la duplicazione, si finisce per aggiungere molta struttura aggiuntiva nel codice del test unitario (cioè quando si porta DRY agli estremi), si corre il rischio di introdurre bug lì. In una situazione del genere, dovresti o testare l'unità dei test unitari o lasciare frammenti di struttura non testati.

Non voglio duplicare lo sforzo qui, ma puoi avere dei test DAMP ma con il vantaggio di DRY. D'altro canto, in alcuni casi i test DRY non soddisfano i test DAMP.

Ho scritto un blog su DRY vs DAMP che include alcuni esempi.

Nessuno dei due approcci dovrebbe essere la tua unica soluzione, a volte DAMP è eccessivo, altre volte un'aggiunta molto piacevole.

Come regola generale è necessario applicare la regola di tre. Se si individua la duplicazione una terza volta, può valere la pena esaminare i test di stile DAMP, ma anche in questo caso non tutta la duplicazione è negativa . Il contesto è importante.