Sollte ich Tests für Komfortüberladungen duplizieren?

Question

Es ist wirklich üblich für mich, Convenience-Überladungen für Methoden zu machen. Hier ist ein Beispiel für etwas, das ich tun könnte:

public void Encode(string value) { 
    Encode(value, DefaultEncoding); 
} 

public void Encode(string value, Encoding encoding) { 
    // ... 
} 

Ich fange mehr Aufmerksamkeit auf Unit-Tests zu zahlen, und Testmethoden wie dies einige Hindernisse einführt Ich bin mir nicht sicher, ob ich vertraue mich allein zu nähern. Das erste und wichtigste Problem ist, ob ich Tests für beide Überladungen duplizieren sollte. Beispielsweise sollten beide Methoden ArgumentNullException werfen, wenn Wert Null ist; ist es richtiger zu erkennen, könnte unterschiedliche Logik sein und zwei Tests schreiben oder ist es besser anzunehmen, dass die Bequemlichkeitsüberlastungen keine Logik ihrer eigenen haben?

Ich habe auch ein sekundäres Problem. Mein Benennungsschema ist dasselbe wie Roy Osheroves: "MemberName_State_ExpectedResult". Wenn ich Tests dupliziere, dann habe ich widersprüchliche Namen, ohne irgendeine seltsame Namenskonvention einzuführen. Wie gehst du damit um, wenn du Tests duplizierst?

Answer 1

Ich teste die Bequemlichkeitsmethoden häufig nicht auf dem gleichen Detaillierungsgrad wie die Kernmethode, die sie nennen. Zum Beispiel Ihr Fall ArgumentNullException. Ich würde es nicht zweimal testen. Mein Gefühl ist, dass Unit-Tests White-Box-Tests sind. Ich darf die Implementierung kennen.

Natürlich könnte dies bedeuten, dass ich verbrannt werde, wenn ich später umgestalten und Funktionalität zur Komfortmethode hinzufügen. Aber ich bin ziemlich anständig in TDD (kein voller Zelot, wie Sie aus dem ersten Absatz sehen können). Ich denke, ich würde wahrscheinlich einen Test für diese neue Funktionalität schreiben und ihn dann abdecken.

Ich behaupte nicht, dass es mehr oder weniger korrekt ist. Es ist genau das, was ich mache.

Answer 2

Wenn alle Ihre Konstrukteure den vollständig angegebenen Konstruktor aufrufen, würde ich die Tests in
1) Ihre aktuellen Unit-Test durchbrechen, die so etwas wie
ConstructorShouldDoThisAndThat sein muss()
2) spezialisierte Unit-Tests für die Überlastungen Angabe, was die Überlastung Anwendungen, wie ConstructorWithNoEncodingShouldSetEncodingToDefaultEncoding Standard()

Answer 3

„zwei Tests schreiben, oder ist es besser, anzunehmen, dass die Bequemlichkeit Überlastungen keine Logik ihrer eigenen haben?“

Umm .... Ihre Tests sind nicht durch "Annahmen" definiert. Sie sind durch das Design der Klasse definiert, die Sie testen.

Sie tun nichts basierend auf "Annahmen".

Wenn die Komfortfunktion ist eigentlich eine Komfortfunktion, es muss das Gleiche tun, und Sie müssen einen Test schreiben, dass Methoden beiden Varianten zeigt tatsächlich das gleiche tun.

Wenn „es könnte andere Logik sein“ (1) es ist nicht wirklich eine Komfortfunktion und (2) Sie müssen einen Test schreiben, dass Methoden beiden Varianten demonstriert tatsächlich die richtige Sache tun (was mit unterschiedlicher Logik gleich sein kann, oder auch anders sein kann, kann ich aus der Frage nicht ableiten.)

"MemberName_State_ExpectedResult. Wenn ich Tests duplizieren, dann habe ich clashing Namen"

töricht Konsistenz Fragen vermeiden. Wenn Sie die gleiche Methode mit verschiedenen Signaturen haben, dann ist diese Namenskonvention nicht sehr gut, oder? Es ist eine törichte Konsequenz, trotz aller Probleme treu zu bleiben.

Sie können dies nicht trivial verwenden, wenn Sie Methoden haben, die nur durch Argumentsignaturen unterschieden werden. Also machen Sie einfach etwas, das für alle Ihre Komfortfunktionen funktioniert.

Answer 4

Ich denke, die Antwort ist einfacher als Sie denken: interessiert es Sie, ob die überladenen Methoden funktionieren oder nicht? Wenn es Ihnen wichtig ist, dass sie funktionieren, wie können Sie das sicher wissen, wenn Sie sie nicht testen?

Es sollte ungefähr 15 Sekunden dauern, um einen Test zu schreiben, der die Ausgabe der überladenen Funktion mit der überladenen Funktion vergleicht. Mach es und geh weiter.

Answer 5

Was ich normalerweise mache, ist die "echte" Methode virtuell zu machen. Das bedeutet, dass ich die Bequemlichkeitsmethode testen kann, indem ich eine testspezifische abgeleitete Klasse verwende (normalerweise erstellt durch einen dynamischen Schein), um zu verifizieren, dass sie die "echte" Methode korrekt aufruft.

Wenn der einzige Unterschied zwischen der "echten" Methode und der Komfortmethode die Verwendung eines Standardwerts für einen bestimmten Parameter ist, können Sie dies mit einem einzelnen Komponententest abdecken und weitermachen.

Ich zweite S.Lott's Antwort hinsichtlich der Namenskonvention.