Unit Testing, TDD und BDD – das alles sind zur Zeit – außer dem Visual Studio 2010 Launch natürlich – aktuelle Themen, die die .NET Community ein Stückweit bewegt. Ich z.B. habe vor ein paar Wochen angefangen, intensivere Forschungen zur Verwandschaft & Beziehung zwischen TDD und BDD durchzuführen. Ich habe zwar schon einige TDD- und BDD-Frameworks hinter mir, doch nicht zuletzt die in jüngster Zeit individuellen, manchmal irritierenden Aussagen zu TDD und BDD geben mir Anlass genug, nachzuforschen.

Ein Bereich, den ich mir dabei näher angeschaut habe ist das Tooling. Ich wurde in der Vergangenheit schon öfters gefragt, welches Test-Framework ich denn einsetze. In letzter Zeit werde ich aber auch ab und an gefragt, welches Test-Framework denn jetzt besser sei. Als Hilfestellung zur Findung einer Antwort auf diese Fragen sowie einen Überblick über die gängigsten Test Frameworks soll dieser Artikel beitragen.

Die Kandidaten

Mit diesem Artikel beginnt die kleine Blog-Serie “Meta-Test”, die Stück für Stück die populärsten Test-Frameworks für .NET und C# unter die Lupe nimmt, sie bewertet und natürlich auch vergleichen wird. Bisher gab es schon folgende Tests:

• MS Test – Visual Studio On Board Test-Framework
• NUnit – All-Time-Hall-Of-Fame-Most-Valueable-Tester
• NSpec – der spezifizierende BDD-Veteran

Die Hypothese

Vorab möchte ich allerdings noch eine – für mich wichtige – Anmerkung äußern. Beim Test der Testframeworks habe ich mehrere Code Kata’s mit allen Frameworks geschrieben. Am häufigsten habe ich wohl FizzBuzz geschrieben, gefolgt von Replacer, LineCounter und ein paar Mal Minesweeper. Ich habe dabei schon deutliche Unterschiede nicht nur in den Frameworks, sondern auch in der Adaption selbst festgestellt. Für den hier gezeigten Vergleich gelten folgende Hypothesen:

• TDD & BDD sind gleichwertig.
• TDD & BDD sind prinzipiell das Gleiche, mit Unterschieden in Benennung und Teststruktur
• TDD & BDD wendet man für die selbe Aufgabe an, zum Software-Design

So, und jetzt der Disclaimer:
Achtung: Die genannten Hypothesen sind nicht meine Meinung über TDD bzw. BDD!

Ganz im Gegenteil. Ich habe zu TDD ein gefestigtes Meinungsbild. Ich habe auch Erfahrung mit BDD. Gerade deswegen bin ich sehr vorsichtig mit beiden Begriffen. Ich denke, TDD und BDD sind nicht das Gleiche. Doch eine weitere Vertiefung in das Thema lenkt nur von den Frameworks ab. Deswegen wieder schnell zurück zu den Test-Frameworks.

Die Anforderungen

Als Entwickler möchte man ein möglichst effektives und intuitives Test-Framework als Werkzeug, um testgestriebenes Softwaredesign durchzuführen. Beim programmieren mit Visual Studio zum Beispiel, wenn man die Tests für die gerade zu entwickelnde Klasse oder Methode formuliert, da gehört die Unterstützung von Tools wie Resharper, CodeRush oder Gallio heutzutage schon zum guten Ton.

Ebenso geht es bei dem Vergleich um die Anwendbarkeit und Effizienz. Also wie expressiv, wie deutlich kann ich meine Tests formulieren und wie intuitiv ist die Umsetzung der Tests. Die Umsetzungsgeschwindigkeit spielt dabei genauso eine Rolle wie die Lesbarkeit, Wartbarkeit und gutes Reporting. Dazu noch später mehr.

Das Ziel

Um auch eine konkrete, relativ faire Vergleichssituation zu erreichen, stelle ich alle Frameworks an einem einzigen Beispiel vor, nämlich dem KataFizzBuzz. FizzBuzz ist eine sehr einfache Kata, die gerade genug “Widerstand” bietet, um die Grundzüge des treibenden Software-Designs sowie des Test-First zu vermitteln. Ich habe mich bei der Programmierung der Kata sogar nur auf das Teilproblem der “Fizz”- und “Buzz”-Übersetzung konzentriert. Es gibt unzählige Implementierungen von FizzBuzz. Bei dem Vergleich der Test-Frameworks habe ich mich für die “triviale” und “zügige” Implementierung entschlossen. Konkretisiert bedeutet dies, das es mein Test-Ziel war, das ich mit allen Test-Frameworks ungefähr folgenden Code produziere:

    public class FizzBuzz
    {
        public string Translate(int number)
        {
            if (number % 15 == 0)
                return "FizzBuzz";

            if (number % 5 == 0)
                return "Buzz";

            if (number % 3 == 0)
                return "Fizz";

            return number.ToString();
        }
    }

Die Metriken

Um nun die einzelnen Frameworks untereinander vergleichen zu können, braucht es nicht nur einer gemeinsamen Basis & Ziels, sondern auch einer gemeinsamen Messmetrik. Um es nicht zu theoretisch zu gestalten, habe ich einige ganz einfache, aber wie ich finde dennoch aussagekräftige Metriken ausgewählt:

• Die Dauer der Implementierung
• Die Größe der Test-Artefakte (Klassen usw.)
• Das Tooling, also die Unterstützung durch VS / Frameworks / Codetools
• Die Usability, also handbuchnachschlagefreie Handhabung der API / Tools
• Der Support durch Hersteller, Community und User

Doch die wichtigste Metirk ist mit Abstand die Bewertung des Ergebnisses der Test-Frameworks – also der Tests ansich. Die Tests werden unter die vier Grundmerkmale Intuitivität, Expressivität, Lesbarkeit und Wartbarkeit gestellt. Natürlich bleibt da meine eigene subjektive Note an der ein oder anderen Stelle hängen, schließlich habe ich die Frameworks eigenständig getestet und habe auch keinen Anspruch auf gestelzte Objektivität .

So, damit sollten die Vorbereitungen und Rahmenbedinungen für den ultimativen Vergleich der Test-Frameworks für das .NET Framework & C# abgeschlossen sein. Dieser gigantische Vergleich von einer Unmenge an Test-Frameworks – für den ich keine Kosten und Mühen gescheut habe – wird als Blog-Post-Serie in den nächsten Tagen veröffentlicht.

Stay tuned!