Was bedeutet "DAMP not DRY", wenn es um Unit-Tests geht?

Ich hörte jemanden sagen, dass Unit-Tests (zB nUnit, jUnit, xUnit) sein sollten

DAMP nicht trocknen

(ZB sollten Unit-Tests "feuchten Code" und nicht "trockenen Code" enthalten.)

Worüber reden sie?

Es ist ein Gleichgewicht, kein Widerspruch

DAMP und DRY sind kein Widerspruch, sondern gleichen zwei verschiedene Aspekte der Wartbarkeit eines Codes aus . Wartbarer Code (Code, der leicht zu ändern ist) ist hier das ultimative Ziel.

DAMP (Descriptive And Meaningful Phrases) fördert die Lesbarkeit des Codes.

Um Code zu pflegen, müssen Sie zuerst den Code verstehen. Um es zu verstehen, muss man es lesen. Überlegen Sie sich für einen Moment, wie viel Zeit Sie mit dem Lesen von Code verbringen . Das ist viel. DAMP erhöht die Wartbarkeit, indem die zum Lesen und Verstehen des Codes erforderliche Zeit verkürzt wird.

DRY (Wiederholen Sie sich nicht) fördert die Orthogonalität des Codes.

Durch das Entfernen von Duplikaten wird sichergestellt, dass jedes Konzept im System eine einzige autorisierende Darstellung im Code hat. Eine Änderung eines einzelnen Geschäftskonzepts führt zu einer einzelnen Änderung des Codes. DRY erhöht die Wartbarkeit, indem Änderungen (Risiken) nur auf diejenigen Teile des Systems beschränkt werden, die sich ändern müssen.

Warum ist die Duplizierung in Tests akzeptabler?

Tests enthalten häufig inhärente Duplikate, da sie immer wieder dasselbe testen, nur mit geringfügig unterschiedlichen Eingabewerten oder Setup-Codes. Im Gegensatz zum Produktionscode ist diese Duplizierung jedoch normalerweise nur auf die Szenarien innerhalb eines einzelnen Testgeräts / einer einzelnen Testdatei beschränkt. Aus diesem Grund ist die Duplizierung minimal und offensichtlich, was bedeutet, dass sie ein geringeres Risiko für das Projekt darstellt als andere Arten der Duplizierung.

Darüber hinaus verringert das Entfernen dieser Art von Duplikaten die Lesbarkeit der Tests. Die Details, die zuvor in jedem Test dupliziert wurden, sind jetzt in einer neuen Methode oder Klasse versteckt. Um ein vollständiges Bild des Tests zu erhalten, müssen Sie jetzt alle diese Teile mental wieder zusammensetzen.

Da das Duplizieren von Testcode häufig ein geringeres Risiko birgt und die Lesbarkeit fördert, ist es leicht zu erkennen, wie es als akzeptabel angesehen wird.

Bevorzugen Sie im Produktionscode DRY und im Testcode DAMP. Während beide gleich wichtig sind, können Sie mit ein wenig Weisheit das Gleichgewicht zu Ihren Gunsten kippen.

DAMP - Beschreibende und aussagekräftige Sätze.

"DAMP not DRY" bewertet die Lesbarkeit über die Wiederverwendung von Code. Die Idee von DAMP not DRY in Testfällen ist, dass Tests leicht zu verstehen sein sollten, auch wenn dies bedeutet, dass Testfälle manchmal wiederholten Code haben.

Siehe auch Ist doppelter Code in Komponententests tolerierbarer? für einige Diskussionen über die Vorzüge dieses Standpunkts.

Es kann von geprägt worden sein Jay Fields in Bezug auf domänenspezifische Sprachen geprägt.

"DRY" ist "Wiederhole dich nicht"

Dies ist ein Begriff, der verwendet wird, um Benutzer anzuweisen, wiederverwendbaren Code zu schreiben, damit Sie nicht immer wieder ähnlichen Code schreiben.

"DAMP" ist "beschreibende und aussagekräftige Sätze".

Dieser Begriff soll Ihnen sagen, dass Sie Code schreiben sollen, der für jemanden, der ihn betrachtet, leicht verständlich ist. Wenn Sie diesem Prinzip folgen, haben Sie lange und beschreibende Variablen- und Funktionsnamen usw.

Damp = 'Beschreibende und aussagekräftige Sätze' - Ihre Komponententests sollten "gelesen" werden können:

Die Lesbarkeit ist wichtiger als die Vermeidung von redundantem Code.

Aus dem Artikel:

DAMP steht für „beschreibende und aussagekräftige Phrasen“ und ist das Gegenteil von DRY, nicht in dem Sinne, dass „alles wie ein Müllhaufen aussehen und nicht lesbar sein sollte“, da Lesbarkeit wichtiger ist als die Vermeidung redundanten Codes.

Was bedeutet das und wo soll es verwendet werden?

DAMP gilt meistens beim Schreiben von Testcode. Der Testcode sollte so einfach zu verstehen sein, dass eine gewisse Redundanz akzeptabel ist.

DAMP steht für „beschreibende und aussagekräftige Phrasen“ und ist das Gegenteil von DRY, nicht in dem Sinne, dass „alles wie ein Müllhaufen aussehen und nicht lesbar sein sollte“, da Lesbarkeit wichtiger ist als die Vermeidung redundanten Codes.

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

Hier gibt es bereits mehrere Antworten, aber ich wollte noch eine hinzufügen, da ich nicht dachte, dass sie es unbedingt so gut wie möglich erklären würden.

Die Idee von DRY (Wiederholen Sie sich nicht) ist, dass Sie in Ihrem Anwendungscode redundanten oder reptetischen Code vermeiden möchten. Wenn Sie etwas haben, das Ihr Code mehrmals ausführen muss, sollten Sie eine Funktion oder Klasse dafür haben, anstatt ähnlichen Code an mehreren Stellen zu wiederholen.

Dies ist ein ziemlich bekanntes Programmierkonzept.

DAMP (Descriptive and Meaninful Phrases) ist für Ihre Unit-Tests. Die Idee dabei ist, dass die Namen Ihrer Unit-Test-Methoden lang und beschreibend sein sollten - effektiv kurze Sätze, die beschreiben, was Sie testen.

z.B: testWhenIAddOneAndOneIShouldGetTwo() { .... }

Wenn Sie einen solchen DAMP-Methodennamen lesen, sollten Sie genau verstehen, was der Testschreiber erreichen wollte, ohne den Testcode lesen zu müssen (obwohl der Testcode diesem Konzept natürlich auch mit wortreichen Variablennamen folgen kann). usw).

Dies ist möglich, weil eine Unit-Test-Methode sehr spezifische Eingaben und erwartete Ausgaben aufweist, sodass das DAMP-Prinzip für sie gut funktioniert. Es ist unwahrscheinlich, dass Methoden in Ihrem Hauptanwendungscode spezifisch genug sind, um solche Namen zu rechtfertigen, insbesondere wenn Sie sie unter Berücksichtigung des DRY-Prinzips geschrieben haben.

DAMP und DRY widersprechen sich nicht - sie decken verschiedene Aspekte der Codierung Ihres Codes ab -, werden jedoch normalerweise nicht zusammen verwendet, da Methoden, die unter Berücksichtigung des DRY-Prinzips geschrieben wurden, universell einsetzbar und wahrscheinlich nicht geeignet sind zu hochspezifischem Methodennamen. Im Allgemeinen sollte Ihr Anwendungscode daher, wie oben erläutert, DRY und Ihr Unit-Test-Code DAMP sein.

Ich hoffe, das hilft, es ein bisschen besser zu erklären.

Ich stimme Chris Edwards darin zu, dass Sie ein Gleichgewicht zwischen beiden finden müssen. Eine andere Sache, die Sie beachten sollten, ist, dass Sie beim Versuch, Duplikate zu entfernen, Ihrem Unit-Test-Code eine Menge zusätzlicher Strukturen hinzufügen (dh wenn Sie DRY auf die Spitze treiben), das Risiko eingehen, dass dort Fehler auftreten. In einer solchen Situation müssten Sie entweder Ihre Unit-Tests Unit-Tests durchführen oder Strukturteile ungetestet lassen.

Ich möchte den Aufwand hier nicht wiederholen, aber Sie können Tests durchführen, die DAMPF sind, aber den Vorteil von DRY haben. Auf der anderen Seite werden DRY-Tests in einigen Fällen die DAMP-Tests nicht erfüllen.

Ich habe über DRY vs DAMP gebloggt, das einige Beispiele enthält.

Keiner der beiden Ansätze sollte Ihre einzige Lösung sein, manchmal ist DAMP übertrieben, manchmal eine sehr schöne Ergänzung.

In der Regel sollten Sie die Dreierregel anwenden. Wenn Sie die Duplizierung ein drittes Mal entdecken, lohnt es sich möglicherweise, DAMP-Stiltests zu schreiben, aber selbst dann ist nicht jede Duplizierung schlecht . Kontext ist wichtig.