2011-01-13 15 views
1

Wenn ich eine Hilfsmethode wie unten habe, wie soll ich Unit-Test testen? Es scheint so, als ob ich, wenn ich feststellen wollte, dass die Ausgabe korrekt war, den Code in die Testmethode einbauen müsste? Ich konnte sehen, ob es eine bedingte Logik gab, wie zum Beispiel, wenn die Eingabezeichenfolge leer ist, gebe null zurück, aber das Testen auf korrekte Ausgabe scheint schwierig zu sein.Unit Testing Utility-Methoden

public static string EncodeTo64(string input) 
{ 
    byte[] b = System.Text.ASCIIEncoding.ASCII.GetBytes(input); 
    string returnValue = System.Convert.ToBase64String(b); 
    return returnValue; 
} 
+2

„Es scheint, als ob ich wollte feststellen, dass die Ausgabe korrekt war Ich würde den Code in die Testmethode einbauen müssen "- Es gibt eine Schule von TDD, die besagt, dass Sie genau das für ALLE Komponententests tun sollten; Schreiben Sie Code in den Test, der das gewünschte Ergebnis liefert, und refaktorieren Sie die Logik dann in Ihre Hilfsmethode. Es ist eher ein Lehrmittel für das Konzept, aber nicht weniger gültig in diesem Fall. – KeithS

Antwort

5

Ich würde es testen, indem ich einen Wert eingab, wusste ich die korrekte Ausgabe von. Entweder durch vorherige Berechnung oder durch Vergleich mit einem bekannten Wert. Sie können wahrscheinlich die Ausgabe für eine kurze Zeichenfolge selbst berechnen.

Weiter würde ich das Verhalten der Methoden für Randbedingungen wie Null-Werte und leere Zeichenfolgen testen.

1

Es hängt davon ab, was die Bedeutung von "Korrektheit" für diese Funktion für Sie als Entwickler bedeutet. Ich würde eine bekannte Zeichenkette in die Ausgabe konvertieren, überprüfen, ob das für mich relevant ist, und dann vergleichen, dass das Ergebnis der Funktion mit dem Ergebnis übereinstimmt, das ich erzeugt habe. Etwas wie folgt aus:

const string expectedBase64String = "abc123$$%++"; 
const string testString = "Not the base 64 source of above"; 

Assert.AreEqual(expected, Utility.EncodeTo64(testString)); 

Sie sind im Wesentlichen richtig ... Sie müssen auf eine andere Definition der Richtigkeit anders als das Verhalten des Codes verlassen, es sei denn alles, was Sie testen müssen, ist „diese noch produziert was es getan hat, als ich es das erste Mal ausgeführt habe ".

0

Verwenden Sie eine vordefinierte Eingabe und die daraus resultierende korrekte Ausgabe und vergleichen Sie sie mit dem, was Ihre Methode produziert. Tun Sie dies für mehrere Eingabe/Ausgabe-Paare, um die Gesamtkorrektheit Ihrer Methode zu testen.

1

Mit ein paar Ausnahmen würden Sie die Ausgabe überhaupt nicht testen, weil das von einer anderen Einheit implementiert wird - der System.Convert Klasse, und es ist bereits gut getestet.

Es würde Sinn für Tests zu schreiben, die dokumentieren, was die Methode tut, wenn Sie es ungewöhnliche Eingänge passieren: null, string.Empty, Strings mit Nicht-ASCII-Codierungen, etc ..

+0

Natürlich sollten Sie die Ausgabe testen. Die Methode könnte einen Fehler wie die Verwendung der falschen Codierung haben –

+2

@Rune FS - Ich stimme zu, dass Sie testen sollten, was passiert, wenn Sie die falsche Codierung verwenden (und sogar das in meiner Antwort erwähnt). Man sollte jedoch keine Komponententests schreiben, um das Verhalten von 'System.Convert' zu überprüfen. –

+0

Stimmen Sie zu, ConvertToBase64 nicht zu testen, aber Sie schreiben "Sie würden die Ausgabe überhaupt nicht testen", was ich nicht stimme, da das heißt, die Ausgabe der Methode nicht zu testen. Die Methode könnte einen Fehler haben wie: System.Text.ASCIIEncoding.Unicode.GetBytes (Eingabe), die Sie nicht in Ihrer Antwort erwähnen –