deesaster.org

In den meisten größeren Software-Projekten stößt man irgendwann auf das Problem, den Code testen zu müssen. In der Regel kommt einem der Gedanken, wenn man den hundersten Bug-Report erhält, der eine ganze triviale Funktion betrifft. Hier können Unit-Tests helfen, die Qualität zu verbessern. Das Buch „The Art of Unit Testing“ von Roy Osherove soll beim Einstieg in das Thema helfen.

Über den Autor

Roy Osherove ist ein bekannter Software-Entwickler und tritt seit mehreren Jahren als Trainer für Unit-Testing und testgetriebene Entwicklung (TDD) auf. Ich lernte ihn auf einem Kurs zum Thema TDD kennen. Das Buch behandelt viele Themen, die er auch in seinen Kursen vermittelt.

Was steht drin?

Hauptaugenmerk des Buches ist natürlich das Unit-Testing. Auch wenn die testgetriebene Entwicklung artverwandt ist und Roy Osherove sich auch hierin auskennt, betont der Autor immer wieder, dass das Buch sich nur wenig damit auseinandersetzen will. So nimmt TDD auch nur einen kurzen Abschnitt am Anfang des Buches ein.

Der größte Teil der Seiten beschäftigt sich also mit dem Thema Unit-Testing. Roy Osherove erklärt anfangs, was man unter Unit-Tests versteht und was die Abgrenzung zu Integrationstest ist. Danach darf man auch gleich seinen ersten Unit-Test schreiben. Für die Umsetzung des Unit-Tests hat sich Roy Osherove für die Sprache C# in Microsoft Visual Studio und das Testframework NUnit entschieden.

Der zweite Teil des Buches geht dann etwas mehr in die Tiefe. So wird sich mit Stubs, Mocks und Fakes beschäftigt, der Unterschied zwischen ihnen erklärt und auch darauf eingegangen, wie man diese korrekt verwendet. Einen großen Teil (35 Seiten) nehmen dabei die Hinweise und Beschreibung von Isolation-Frameworks ein. Konkrete Beispiele gibt es aber nur für .NET.

Teil 3 behandelt den Testcode an sich. So wird erklärt, was einen guten Unit-Test ausmacht, wie beispielsweise Vertrauenswürdigkeit, Wartbarkeit oder Lesbarkeit. Aber auch auf außenstehende Eigenschaften wie Automatisierung und Versionsverwaltung wird eingegangen.

Der letzte Teil 4 behandelt dann einige besondere Themen, die ggf. nicht für jeden Leser gleich relevant sind. Ein Kapitel beschäftigt sich mit der Integration von Unit-Tests in der Organisation und liefert Argumente, wieso Unit-Tests wichtig sein können. Ein anderes Kapitel behandelt Legacy Code, das heißt meist alten, teils verwaisten und mitunter nicht gut strukturierten Code, den man testen möchte. Hier verweist Osherove auch auf das sehr gute Buch „Effektives Arbeiten mit Legacy Code“ von Michael Feathers. Das letzte Kapitel in dem Teil beschäftigt sich mit dem Thema „Design und Testbarkeit“ (Design for Testability), was es leichter machen soll, seinen Code zu testen.

Im Anhang findet man eine Auflistung verschiedener Test- und Isolation-Frameworks, die meisten behandeln davon aber nur .NET als Sprache.

Am Anfang jedes Kapitels findet man eine kurze Beschreibung, was der Text auf den nachfolgenden Seiten erreichen soll. Am Ende eines Kapitels gibt es entsprechend eine Zusammenfassung, die das Gelernte noch einmal kurz beschreibt.

Für wen ist das Buch geeignet?

Laut Osherove ist die Zielgruppe des Buches jede Art von Code-Schreiber, seien es Entwickler, Architekten oder eben Tester. Auf den Wissensstand geht der Autor nicht gesondert ein und hat Recht damit, da das Buch sowohl für Anfänger als auch Fortgeschrittene geeignet ist.

Die Einführung in Unit-Test geht sehr sanft voran und auch zum Ende des Buches hin sind die Beispiele noch übersichtlich und leicht verständlich. Fortgeschrittene können vor allem durch die erweiterten Kapitel bzgl. Legacy Code oder Design for Testability noch etwas lernen.

Schade ist, dass Roy Osherove sich auf C#, Visual Studio und NUnit versteift. Für .NET-Entwickler ist das natürlich praktisch, für alle andere etwas hinderlich. Zwar kann man als C++- oder Java-Entwickler die meisten Beispiele abstrahieren, aber sehr oft wird auf exklusive Features von NUnit eingegangen, die es in anderen Frameworks oder Sprachen nicht gibt. Das macht es schwer, die Beispiele nachzuvollziehen.

Zwingende Voraussetzung für das Verständnis der Beispiele ist aber die objektorientierte Programmierung. Vor allem Stubs und Mocks leben davon, dass man Interfaces und Klassen ableiten und Methoden überschreiben bzw. realisieren kann. Wer keine objektorientierte Sprache nutzt, wird sich schwer tun, den Code zu verstehen bzw. diesen im eigenen Projekt anzuwenden.

Wie liest es sich?

Roy Osherove hat einen guten Schreibstil und auch die Übersetzung von Olaf Neuendorf ist sehr gut gelungen. Toll ist, dass Roy Osherove sein Buch nicht als Dogma auffassen möchte, sondern selbst schreibt, dass sich seine Meinung in einigen Gebieten bis zur nächsten Auflage ändern kann. So empfiehlt er in der zweiten Auflage andere Frameworks als im ersten Versuch und auch einige Programmierparadigmen haben sich geändert. Diese Ehrlichkeit ist gut und als Leser weiß man so von vornherein, dass man sich aus dem Buch nicht alles herauspicken muss, sondern auch nur eine Auswahl treffen kann, was auf das eigene Projekt am besten passt.

Die Beispiele sind fast alle sehr kurz und übersichtlich, sodass man sie leicht verstehen kann. Auch als Nicht-C#-Entwickler kann man mit einem objektorientierten Hintergrund folgen und den Code auf die eingesetzte Sprache der eigenen Wahl anpassen.

Fazit

Insgesamt ist das Buch „The Art of Unit Testing“ sehr empfehlenswert. Es bietet eine sehr gute Einführung in Unit-Tests und bündelt die gesammelten Erfahrungen des Autors. Viele Aussagen sind dabei als Hinweis oder Leitlinie zu verstehen und nicht als Dogma.

Negativ ist die Versteifung auf .NET und NUnit. Beispielsweise kennt nicht jedes Testframework Test-Cases. Da Logik wie Schleifen in einem Unit-Test aber eigentlich auch nicht erlaubt sind, steht man als Entwickler hier vor einem Problem. Auch die Vorstellung der Isolation-Frameworks bzw. Testframeworks im Anhang kann man als Nicht-C#-Entwickler überspringen. Einzig die Erklärung, wie sich Isolation-Frameworks klassifizieren lassen und welche Eigenschaften die verschiedenen Werkzeuge haben, hilft unter Umständen dabei, ein Framework für die eigene, eingesetzte Sprache zu finden.

Sehr gut haben die Kapitel bzgl. Integration in der Organisation und Design for Testability gefallen. Ohne diese wäre da Buch zwar auch nutzbar, aber sie geben wichtige Argumente und Hinweise an die Hand, um Unit-Tests noch besser schreiben bzw. überhaupt erst einmal einsetzen zu können. Das Kapitel zu Legacy Code ist dagegen etwas zu kurz. Hier empfiehlt sich eher das Buch von Michael Feathers „Effektives Arbeiten mit Legacy Code“.