Es ist üblich, Klassen mit Methoden mit Zeichenfolgenparametern zu haben, die wiederum auf null oder leer validiert werden müssen, wie in diesem Beispiel:
%Vor%Es ist klar, dass das Verhalten der Methode für beide (ungültige) Werte gleich ist. Dies ist eine sehr häufige Situation, und wenn es darum geht, diese Methoden zu testen, zweifle ich immer daran, wie es geht. Ich erstelle immer zwei separate Tests für diese Fälle:
%Vor%}
Aber ich sehe zu viel Redundanz. Diese Tests sind genau gleich, mit dem einzigen Unterschied, dass der Parameter an die Methode übergeben wird. Das stört mich sehr, da ich für jeden String-Parameter zwei Tests erstellen muss. Eine Methode mit 3 Parametern würde nur 6 Tests haben, um die Parameter zu testen.
Ich denke, das ist der richtige Weg, diese Parameter zu testen, aber wenn ich weiß, dass 99% der String-Parameter auf die gleiche Weise validiert werden, wäre es nicht besser, sie einfach auf Null (oder leer) zu testen und davon auszugehen das Verhalten in dem anderen Fall wird der gleiche sein?
Ich würde gerne wissen, was Sie darüber denken. Ich weiß, dass das, was ich frage, eher eine technische als eine technische Frage ist, aber ich denke, dass die Testgemeinschaft etwas Interessantes über diese Situation zu sagen hat.
Danke!
Ich persönlich würde mit einem einzigen Test für alle Parameter betrachten. Das folgt nicht dem normalen Dogma der Komponententests, aber es erhöht die Lesbarkeit der Tests (indem es die Menge an Testcode minimiert, die einem ziemlich repetitiven Fall gewidmet ist) und hat nicht viele Nachteile. Ja, wenn der Test fehlschlägt, wissen Sie nicht, ob alle Prüfungen nach dem ersten Fehler auch fehlschlagen - aber ist das wirklich ein Problem in der Praxis?
Wichtig ist, dass Sie eine Abkürzung haben, um den Fall zu testen. Zum Beispiel könnten Sie so etwas schreiben (wenn Ihr Unit-Test-Framework es nicht schon hat):
%Vor%Dann kannst du schreiben:
%Vor% Viel prägnanter als jedes einzelne mit einem einzelnen try / catch-Block oder sogar mit einem ExpectedException -Attribut und mehreren Tests.
Sie möchten möglicherweise Überladungen für Fälle, in denen Sie auch überprüfen möchten, dass in keinem Fall überspannte Objekte berührt wurden (um zu überprüfen, dass Nebenwirkungen vermieden werden) oder möglicherweise Überladungen für häufige Ausnahmen wie ArgumentNullException .
Für Einzelparameter-Methoden könnten Sie sogar eine Methode schreiben, um genau das zu kapseln, was Sie brauchen:
%Vor%rufen Sie es dann mit:
%Vor%... und vielleicht ein weiterer für Methoden mit einem einzelnen Parameter, aber einem nicht-void Rückgabetyp.
Das geht aber möglicherweise ein bisschen weit:)
Tags und Links string testing parameters null