DRY zwischen Produktion und Testcode Konstanten

Question

ich normalerweise versuchen, um Doppelarbeit zu vermeiden und auf das DRY-Prinzip einzuhalten. Allerdings frage ich mich, über einen Fall wie folgt aus:

public class Feature {
    final static String FEATURE_LABEL = "blah";

    public void doSomething() { ... }
    ...
}

public class FeatureTest {
    ...
    @Test
    public void doSomethingShouldMakeSomethingHappen() {
         assertEquals(Feature.FEATURE_LABEL, 
             feature.getSomethingHappens().getLabel());
    }

Wenn die Anforderung ist, dass die das Etikett sein „blah“ und jemand ändert FEATURE_LABEL auf „bleh“, wird der Test bestehen, auch wenn es nicht mehr die Anforderung erfüllt. Ist dies eine gültige Stelle zu verletzen DRY?

Answer 1

Ja, verwenden Sie eine wörtliche hier.

eine Frage zu Literalen :

Fest programmierte Literale in Unit-Tests für die Testwerte angezeigt werden sollen, es sei denn, es gibt so viel Wiederverwendung von einem Wert innerhalb eines einzelnen Testklasse ist, die eine lokale Konstante nützlich ist.

Die Unit-Tests sind eine Beschreibung der erwarteten Werte ohne Abstraktion oder Umleitung. Stellen Sie sich den Test zu lesen -. Sie Informationen buchstäblich vor Sie wollen

Answer 2

etwas testen - alles - ein wichtiger Aspekt ist, dass Ihre Testbedingungen stehen unabhängig von dem, was Sie testen. Andernfalls Sie Ihre Tests nicht eine einzige, zuverlässige Bedeutung haben; sie verwandeln sich in einen anderen Test des Untersuchungsobjekt ändert jedes Mal.

Nicht eine sehr gute Sache.

Die gleiche Idee gilt für Unit-Tests. In einem Kontext wie oberhalb der Saite gegen zu test Sie absolut unabhängig sein sollten, was in der getesteten Klasse ist. Mit anderen Worten, ja, Sie können und sollte verletzt das DRY-Prinzip hier.

Answer 3

Eine andere Art und Weise zum Ausdruck bringen, was die andere schon gesagt: Wenn der Test kann nie fehlschlagen, gibt es keinen Punkt ist es zu halten. So würde dies keinen Sinn machen:

assertEquals(Feature.FEATURE_LABEL, Feature.FEATURE_LABEL);

Nehmen wir zum Beispiel haben Sie eine Grenze für eine Liste. Es gibt keinen Punkt in der Prüfung, die == Grenze zu begrenzen, sollte der Test versuchen, mehr als Begrenzungselemente in die Liste zu setzen.

OTOH, wenn Sie sicherstellen möchten, dass die Konstanten in der richtigen Stelle verwendet wird (dh es sollte wie das Etikett an einem gewissen UI-Element verwendet werden), ist es sinnvoll ist, den Test mit der String-Konstante zu verwenden (anstelle von ein neues wörtliche).

Das heißt, für meine eigene UI-Tests, ich Schaber verwenden, die alle Strings sammeln sichtbar und vergleichen Sie die resultierende (lange) Zeichenfolge mit dem Inhalt einer Datei. Dies ist ein sehr einfacher catch-all-Test für unerwartete Änderungen in der Benutzeroberfläche und funktioniert am besten für UIs in HTML (I die HTML-Download und vergleichen Sie es), aber das gleiche Muster kann auf jede UI angewandt werden.

Answer 4

Ich würde im Moment mit der Referenz bleiben.

Die Sache ist, wenn die Anforderung Änderungen, die sollte auslösen jemand einen Test zu ändern. Wohl der richtige Weg, um den Test zu ändern, ist es auf den neuen Wert als Literal zu ändern, finden Sie es nicht, die Produktion statische ändern, finden Sie sie passieren, dann den Test auch die Produktion statisch wieder ändern zu verwenden und sieht es immer noch passieren.

Macht das Sinn?

Answer 5

Ich denke, was Sie haben, ist gut, und ja, es ist eine gültige Verwendung von DRY: wenn dieser Wert in mehreren Tests, um am Ende wird Sie nicht wollen, wenn der Wert ändert mehrere ändern. Aber Sie sollten auch einen zusätzlichen Test, den man hinzufügen, die den Wert von Feature.FEATURE_LABEL bestätigt.

Dies ist ein guter Ort „einmal und nur zweimal“ gelten: Wenn Sie nur einen einzigen Test haben, wo der Wert von FEATURE_LABEL getestet wurde, dann würde ich einfach die Zeichenkette verwenden. Es ist nur, wenn Sie es mehrere Tests haben mit, wo ich anfangen würde die Referenz verwendet (und einen Test für den Wert hinzufügen).