Mit knapp 2 Monaten Verspätung folgt nun also der zweite Teil dieser kleinen Serie 
Die IDE ist das meist täglich gebrauchte Werkzeug eines jeden Entwicklers. Unter .NET ist das mit Abstand am meisten verbreitete Exemplar dieser Gattung Visual Studio in den verschiedenen Ausprägungen. Wie bereits in Teil 1 geschrieben, erachte ich die Wahl der IDE als sekundär, Hauptsache der Entwickler findet sich damit zu Recht – also vergleichbar mit den Kochmessern eines Küchenchefs
Dieser Artikel wird zeigen, wie man mittels Visual Studio 2008 seine Projekte mit UnitTests testet. UnitTests sollten genauso ein Selbstverständnis für einen Entwickler sein, wie auch alle anderen Punkte dieser Serie. Ich möchte hier nicht ins Detail gehen, das machen andere schon sehr gut – trotzdem aber die wichtigsten Punkte, um was es beim Unit-Testing geht. Zuerst also etwas Theorie.
Definition
Für ne schlaue Definition muss wiedermal Wikipedia herhalten:
“(…) unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application.”
Also – man testet den kleinst-möglichen testbaren Teil einer Applikation – und das ist per Definition in einer OO-Anwendung natürlich die Methode. Dieser scheinbar unspektakuläre Satz, beeinhaltet schon einige der Grundsätze von Unit Tests.
- Jeder Unit-Test testet genau eine Methode, nicht mehr und nicht weniger. Es werden also keine ganzen Abläufe (z.B. Abfolge von Method-Calls) getestet.
- Das Resultat eines Unit-Tests sagt aus, ob die Methode (und nur genau die) gemäss dem definierten Testfall korrekt funktioniert.
Unit-Tests sollten immer möglichst einfach gehalten werden, dies reduziert das Risiko von Fehler im Test selbst.
Test-Driven Development
Im Zusammenhang mit Unit-Tests wird oftmals von Test-Driven Development (TDD) gesprochen. Wie der Name schon sagt, geht es dabei darum, mittels Tests zur eigentlichen Implementation zu kommen. Neue Funktionen werden stets gegen die zuvor definierten Testfälle implementiert und getestet. Eine Funktion gilt dann als implementiert, wenn diese alle für sie definierten Testfälle erfolgreich durchlaufen kann. In diesem Zusammenhang ebenfalls wichtige Konzepte sind
- KISS – Keep it simple, stupid
- YAGNI – You ain’t gonna need it
Wichtiger Punkt im TDD ist also, nur genau das zu implementieren, was auch gefordert wird – und alles was gefordert wird, muss als Testfall hinterlegt sein. Jede Funktion die zusätzlich implementiert wird, quasi als gutgemeinten Bonus, ist nicht getestet (zumindest durch Unit-Tests) und stellt daher eine Verletzung dieser Prinzipien dar.
Die Regeln des Test-Driven Development
Der Ablauf beim TDD erscheint vielen Entwicklern anfangs etwas umständlich und gewöhnungsbedürftig. Auch scheinen die Regeln teils etwas überbestimmt. Trotzdem hat jede dieser Regeln ihre Berechtigung.
- Schreibe den Test
Hier werden viele bereits stutzig. Den Test vor der eigentlichen Methode schreiben? Genau! Denn die Methode soll ja vom Test abhängen und nicht umgekehrt. Andersrum besteht immer die Gefahr, dass der Test um die Methode gebaut wird. Man testet das, was man weiss das die Methode kann – und nicht was sie können sollte.
- Implementiere die Methode so, dass sie (und der zuvor definierte Test) gerade mal kompiliert, der Test aber fehlschlägt
Dieser Punkt wird oft ignoriert, da er so trivial erscheint. Der Punkt, dass der Test aber immer zuerst fehlschlagen soll, ist sehr zentral, da auch ein Test – wie jedes andere Stück Software auch – prinzipiell Fehler enthalten kann. Das heisst, der Test könnte immer erfolgreich sein, obwohl der Case gar nicht erfüllt ist. Dieser Punkt ist also quasi der Test des Tests.
- Implementiere die Methode so, dass sie den Testfall besteht
Nun gehts also ans Eingemachte, die Methode soll ihre Implementation erhalten, und zwar so, dass sie den zuvor geschriebenen Test erfolgreich durchläuft. Wichtig dabei ist, dass hier noch nicht die ultimative Super-Lösung gebaut werden soll. Es soll in erster Linie mal einfach funktionieren. Nachdem in Punkt 2 ja getestet wurde, dass der Test fehlschlägt wenn er soll, muss jetzt ja auch mal gezeigt werden, dass er zu einer funktionierenden Methode auch sein “OK” gibt.
- Refactor
Nun wird die laufende Lösung von Punkt 4 mittels Refactoring “verschönert”. Der Test muss danach natürlich immer noch korrekt durchlaufen werden.
- Starte wieder bei Punkt 1
Eine Methode hat in den seltensten Fällen nur einen Testfall. Da die Fälle sehr einfach gehalten werden sollen, gibt es hier meist ein ganzes Set von Tests pro Funktion. Dieser Punkt streicht den iterativen Ansatz dieser Methodik hervor. Die Implementation wächst also iterativ mit jedem Testfall, und ist genau dann fertig, wenn keine weiteren Fälle mehr zu definieren sind und alle definierten Fälle erfolgreich abgeschlossen werden können.
Wieso denn nun das ganze? Die Vorteile die aus dieser Vorgehensweise entstehen sollten für sich sprechen:
- Fehlerfreie Software?
Nicht ganz – aber man weiss zumindest, und kann auch jederzeit nachprüfen, dass eine Funktion mit den definierten Testfällen klar kommt. Natürlich heisst das noch lange nicht, dass damit die Software korrekt funktioniert oder gar fehlerfrei ist. Jedoch kann man von einem gewissen Grad an Korrektheit ausgehen. Sollten trotzdem Fehler auftreten, waren die Testfälle nicht ausreichend.
- Entspannte Änderungen
Jeder kennt das, man muss an einer Software etwas ändern und man ist sich vielleicht nicht ganz 100%ig über die Konsequenzen im Klaren. Side-Effects treten ja meist an den Stellen auf, an denen man sie am wenigsten vermutet. Kann der Entwickler jedoch nach seiner Änderung auf eine Fülle von erfolgreich abgearbeiteten Testfälle blicken, wird das sein Vertrauen merklich steigern. Auch hier gilt aber natürlich Vorsicht, die Änderung kann trotzdem Fehler verursachen! Evtl. müssen für die Änderung auch neue Tests eingeführt werden.
- Dokumentation
Auch diese Situation ist wohl den meisten bekannt – man hat eine Methode vor sich und kann irgendwie nicht so greifen, was diese überhaupt genau macht. Die “erklärenden” Sätze in den Kommentaren machen das ganze auch nicht einfacher. Die Testfälle hingegen zeigen mit sehr übersichtlichem und einfachem Code, was die Methode zu erfüllen hat.
- Lose Kopplung
Dies kommt praktisch gratis mit TDD mit. Denn wer so vorgeht, wird automatisch wenig Abhängigkeiten erzeugen. Abhängigkeiten sind immer irgendwo problematisch beim testen – da wird man sich also hüten.
Die Krux mit den Abhängigkeiten
Wie bereits geschrieben, sind Abhängigkeiten ein grundsätzliches Problem beim Unit-Testing. Man stelle sich zum Beispiel vor, man möchte eine Methode einer Datenbankzugriffsklasse testen. Beim schlichten Aufruf dieser Methode wird automatisch auch die Datenbank aufgerufen. Was test man so nun? Funktioniert das Db-Statement? Ist die Datenbank erreichbar? Oder doch nur ob die Funktion korrekt funktioniert? Ja genau – alles zusammen, und doch wieder nichts. Wenn was schief geht, ist nicht klar warum. Daraus ergeben sich einige Grundregeln, die man beim Schreiben der Tests beachten sollte:
Ein Unit-Test sollte nie
- I/O-Funktionalität aufrufen (Filesysteme, Datenbanken, Netzwerk… alles tabu)
- auf ein Konfigurations-File angewiesen sein
- von anderen Unit-Tests abhängig sein. Jeder Test muss für sich allein funktionieren.
Solche Abhängigkeiten werden mit Hilfe von Mock-Objekten nachgebaut. Hierzu wird nächstens ein eigener kleiner Artikel folgen.
Wer all dies berücksichtigt – wird glücklich mit TDD – da leg ich meine Hand ins Feuer
TDD mit Visual Studio 2008
Das neue Visual Studio (wie auch das alte ) bietet alles, was man zu TDD benötigt. Zur Veranschaulichung ziehen wir mal so ein Szenario durch. Als Beispiel dient uns eine Applikation, die beliebige Zeichenketten durch verschiedene Sortieralgorithmen sortieren kann – so zum Beispiel mit QuickSort, ein beliebter “Divide and Conquer”-Algorithmus.
Als Ausgangslage dient uns folgender Aufbau der Applikation:
Program.cs beinhaltet etwas Code zur Verarbeitung der Eingabe sowie die schlussendliche Ausgabe des Resultates. ISortAlgorithm ist ein Interface, welches die Schnittstellen eines Sortieralgorithmus’ vorgibt – nämlich:
public interface ISortAlgorithm
{
string Sort(string toSort);
}
Nun haben wir ja vorhin einen schönen Ablauf definiert, also sehen wir mal ob der was taugt:
Punkt 1 – Test schreiben:
An dieser Stelle erlaube ich mir bereits die erste kleine Abweichung obiger Regel. Und zwar erstelle ich mir jeweils aus Bequemlichkeit bereits die Klasse sowie den Methodenrumpf bevor ich den Test schreibe. Das hat den Vorteil, das man beim Test schreiben auf IntelliSense zurückgreifen kann und nicht alles komisch rot unterstrichen erscheint. Ausserdem kann man sich das Gerüst für die Tests gleich in Visual Studio generieren lassen.
Ich erstelle also die Klasse QuickSortAlgorithm und implementiere das obige Interface ISortingAlgorithm. Das ist’s dann aber auch schon. Danach genügt ein Rechtsklick ins Fenster zum Erstellen des Test-Projektes.
In dem generierten File findet sich dann eine Methode SortTest. Dies ist nun also unser Test, dessen Logik wir nun noch zu definieren haben.
[TestMethod()]
public void SortTest()
{
QuickSortAlgorithm target = new QuickSortAlgorithm(); // TODO: Initialize to an appropriate value
string toSort = string.Empty; // TODO: Initialize to an appropriate value
string expected = string.Empty; // TODO: Initialize to an appropriate value
string actual;
actual = target.Sort(toSort);
Assert.AreEqual(expected, actual);
Assert.Inconclusive("Verify the correctness of this test method.");
}
Das TestMethod-Attribut gibt an, dass es sich bei der Methode um einen Test handelt. Dies ist notwendig, damit Visual Studio damit zu Recht kommt.
Um dies zu tun, muss man sich natürlich über die Anforderungen im Klaren sein. Unit-Tests sind WhiteBox-Tests – der Entwickler weiss also von der Implementation, dies ist auch nötig, wie wir später noch sehen werden. Also die Anforderung ist, dass wir der Methode einen String übergeben können und dieser sortiert zurück kommt. Entsprechend passen wir den Test an:
[TestMethod()]
public void SortTest()
{
QuickSortAlgorithm target = new QuickSortAlgorithm();
string toSort = "bda";
string expected = "abd";
string actual;
actual = target.Sort(toSort);
Assert.AreEqual(expected, actual);
}
Sehr schlicht und einfach also das ganze. Gut – und nun zu Punkt 2.
Punkt 2 – Methode implementieren, dass der Test fehlschlägt
Einfach, aber wichtig – also, wir geben einen Wert zurück, der den Test dazu veranlassen müsste, fehlzuschlagen – also zum Beispiel einen Leerstring.
Nun lassen wir den Test ein erstes Mal laufen um zu schauen, ob das Erwartete auch wirklich eintrifft. Ein Weg den Test zu starten ist wiederum über das Kontextmenü der Testmethode:
Und erhält folgendes Resultat:
Wenn das Resultat hier auf “Passed” wäre, wüsste man nun, dass der Test noch fehlerhaft ist, da er offensichtlich falsche Daten also korrekt klassifizierte.
Auf die restlichen Punkte muss hier nicht genauer eingegangen werden. Nun geht es einfach noch darum, die Implementation korrekt zu machen, und weitere Testfälle zu definieren, die sicherstellen, dass der Algorithmus korrekt funktioniert.
Weitere Testfälle wären zum Beispiel:
- weitere Strings die korrekt sortiert werden müssen (spezielle Daten!), erwartet korrekt sortierte Rückgaben
- ein Leerstring als Übergabe, erwartet einen Leerstring als Rückgabe
- null als Übergabe, erwartet eine NullReferenceException
- usw.
Das Beispiel mit einigen definierten Testfällen gibt’s zum Download.
Code Coverage
Die Code Coverage gibt an, wieviel Prozent der Code-Statements durch einen Test abgedeckt werden. Dieser Wert sagt zwar prinzipiell nicht sehr viel aus, man sollte die Coverage aber dennoch immer etwas im Auge behalten. Ziel sollte ein Wert jenseits der 90%-Marke sein.
Mit Visual Studio lässt sich die Code Coverage sehr einfach messen. Hierzu müssen aber zuerst die Assemblies ausgewählt werden, auf denen die Messung stattfinden soll. Das entsprechende Menu findet man hier:
Danach kann man, nachdem die Tests durchgeführt wurden, das Code Coverage-Fenster öffnen und sich die Resultate zu Gemüte führen.
In dem Fenster kann man sich dann auch gleich anzeigen lassen, welche Zeilen durch einen Test abgedeckt werden und welche nicht. So kann man seine Testfälle optimieren.
Dies zeigt nun auch, wieso Unit-Tests eben WhiteBox-Tests sein müssen. Damit die Testfälle alle Verzweigungen einer Methode berücksichtigen kann, muss der Entwickler des Testfalls wissen, wie die Methode implementiert ist.
Natürlich sagt eine CodeCoverage von 100% nicht sonderlich viel aus – es ist weder ein Qualitätsmerkmal für den Code noch für die Testfälle. Es geht dabei mehr darum, zu entdecken, ob gewisse Code-Teile nicht getestet werden.
Fazit
Unit Tests und TDD sind ein grosses und wichtiges Thema. Visual Studio ermöglicht einen komfortablen Einsatz. Seit der 2008-Version, weden Unit-Tests bereits in der Professional-Variante unterstützt. Allerdings geht es auch ohne – Tools hierfür gibt es wie Sand am Meer. Erwähnt seien hier NUnit, NCover und TestDriven.Net (kostenpflichtig).
Viel braucht es also nicht, um Test-Driven entwickeln zu können. Trotzdem stellt sich der Anfang als eher harzig heraus, da es doch eine etwas andere Denk- und Vorgehensweise erfordert. Die Vorteile überwiegen aber doch klar, und wer sich einmal daran gewöhnt hat, wird es nicht mehr missen wollen.
Und hier noch das Beispiel-Programm zum Download:
StringSort.zip (57.99 KB)
Referenzen
Literatur
AAA steht für “Arrange Act Assert” und stellt ein Syntax-Pattern dar. In unserem Beispiel wurde der Test in genau drei solche Teile zerlegt:
