unit-testing
Unit Testing: Best Practices
Suche…
Einführung
Ein Komponententest ist der kleinste überprüfbare Teil einer Anwendung wie Funktionen, Klassen, Prozeduren, Schnittstellen. Unit Testing ist eine Methode, mit der einzelne Einheiten des Quellcodes getestet werden, um zu bestimmen, ob sie für die Verwendung geeignet sind. Komponententests werden grundsätzlich von Software-Entwicklern geschrieben und ausgeführt, um sicherzustellen, dass der Code seinem Design und seinen Anforderungen entspricht und sich wie erwartet verhält.
Gute Benennung
Die Bedeutung einer guten Benennung lässt sich am besten anhand einiger schlechter Beispiele veranschaulichen:
[Test]
Test1() {...} //Cryptic name - absolutely no information
[Test]
TestFoo() {...} //Name of the function - and where can I find the expected behaviour?
[Test]
TestTFSid567843() {...} //Huh? You want me to lookup the context in the database?
Gute Tests brauchen gute Namen. Gute Tests testen keine Methoden, Testszenarien oder Anforderungen.
Eine gute Benennung liefert auch Informationen zum Kontext und zum erwarteten Verhalten. Wenn der Test auf Ihrer Build-Maschine fehlschlägt, sollten Sie im Idealfall entscheiden können, was falsch ist, ohne auf den Testcode zu achten.
Eine gute Benennung erspart Ihnen Zeit zum Lesen von Code und zum Debuggen:
[Test]
public void GetOption_WithUnkownOption_ReturnsEmptyString() {...}
[Test]
public void GetOption_WithUnknownEmptyOption_ReturnsEmptyString() {...}
Für Anfänger kann es hilfreich sein, den Testnamen mit EnsureThat_ oder einem ähnlichen Präfix zu beginnen. Beginnen Sie mit einem "EnsureThat_", um über das Szenario oder die Anforderung nachzudenken, für die ein Test erforderlich ist:
[Test]
public void EnsureThat_GetOption_WithUnkownOption_ReturnsEmptyString() {...}
[Test]
public void EnsureThat_GetOption_WithUnknownEmptyOption_ReturnsEmptyString() {...}
Die Benennung ist auch für Testgeräte wichtig. Benennen Sie das Testgerät nach der getesteten Klasse:
[TestFixture]
public class OptionsTests //tests for class Options
{
...
}
Die endgültige Schlussfolgerung lautet:
Eine gute Benennung führt zu guten Tests, was zu einem guten Design im Produktionscode führt.
Von einfach bis komplex
Wie beim Schreiben von Klassen - beginnen Sie mit den einfachen Fällen und fügen Sie dann Anforderung (aka Tests) und Implementierung (auch Produktionscode) von Fall zu Fall hinzu:
[Test]
public void EnsureThat_IsLeapYearIfDecimalMultipleOf4() {...}
[Test]
public void EnsureThat_IsNOTLeapYearIfDecimalMultipleOf100 {...}
[Test]
public void EnsureThat_IsLeapYearIfDecimalMultipleOf400 {...}
Vergessen Sie nicht den Refactoring-Schritt, wenn Sie mit den Anforderungen fertig sind - zuerst den Code umgestalten und dann die Tests überarbeiten
Wenn Sie fertig sind, sollten Sie über eine vollständige, aktuelle und READABLE-Dokumentation Ihrer Klasse verfügen.
MakeSut-Konzept
Testcode hat die gleichen Qualitätsanforderungen wie der Produktionscode. MakeSut ()
- verbessert die Lesbarkeit
- kann leicht umgestaltet werden
- Unterstützt die Injektion von Abhängigkeiten perfekt.
Hier ist das Konzept:
[Test]
public void TestSomething()
{
var sut = MakeSut();
string result = sut.Do();
Assert.AreEqual("expected result", result);
}
Das einfachste MakeSut () gibt nur die getestete Klasse zurück:
private ClassUnderTest MakeSUT()
{
return new ClassUnderTest();
}
Wenn Abhängigkeiten benötigt werden, können sie hier eingefügt werden:
private ScriptHandler MakeSut(ICompiler compiler = null, ILogger logger = null, string scriptName="", string[] args = null)
{
//default dependencies can be created here
logger = logger ?? MockRepository.GenerateStub<ILogger>();
...
}
Man könnte sagen, dass MakeSut nur eine einfache Alternative für Setup- und Teardown-Methoden ist, die von Testrunner-Frameworks bereitgestellt werden, und diese Methoden möglicherweise einen besseren Platz für testspezifische Setup- und Teardown-Methoden bieten.
Jeder kann selbst entscheiden, welchen Weg er verwenden soll. Für mich bietet MakeSut () eine bessere Lesbarkeit und mehr Flexibilität. Nicht zuletzt ist das Konzept unabhängig von einem Testrunner-Framework.