Back to COBOL – natürlich mit Unit Tests

Ich hätte nie gedacht, dass ich mich nach über 10 Jahren noch einmal mit COBOL beschäftigen würde. Aber nun habe ich ein Team, das mit COBOL arbeitet und Scrum machen soll.

Nun sind COBOL und Scrum zwei Dinge, die die meisten Menschen, die ich so kenne, nicht oft in einem Satz verwenden. Das soll aber kein Grund sein, sich nicht mit der Materie zu beschäftigen. Letztes Wochenende habe ich OpenCOBOL – neuerdings GNU-Cobol – via homebrew auf dem Mac verfügbar gemacht.

Das war aber nur der erste Schritt, denn mein eigentliches Ziel war die Grundvoraussetzung für agile Software-Entwicklung mit COBOL zu nutzen. Na? Genau: Unit Tests! Mit CobolUnit gibt es dafür auch ein Framework, das aber schon seit einer Weile nicht maintained wird. Die letzten Commits sind von 2009, das versprach ein Abenteuer.
Und das wurde es dann auch. Ich habe mich von Fehlermeldungen wie
error: indirect goto in function with no address-of-label expressions
zu
ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '/Users/gbeine/GitHub/gbeine/COBOLUnit/COBOLUnitLib/lib/libCobolUnit.dylib' for architecture x86_64
durchgearbeitet.

Am Ende ist es mir gelungen, CobolUnit mit GNU-Cobol in der Version 1.1 und dem GCC 4.9.1 zum Laufen zu bringen. Das Resultat schaut recht erfreulich aus:

|--- Suite1
| Test 'CTU0S1T1 * SUCCESS * (006 Assertions, 000 Failures. 000 errors)
| Test 'CTU0S1T2 * SUCCESS * (006 Assertions, 000 Failures. 000 errors)
|--- SUCCESS

|--- Suite2
| Test 'CTU0S2T1 * SUCCESS * (008 Assertions, 000 Failures. 000 errors)
|--- SUCCESS

********************************************************************
* SUCCESS *
* (003 test cases, 003 success, 000 failures, 000 errors) *
********************************************************************
(00 min:00 sec:01 ms)

Meine Änderungen dazu habe ich – natürlich – auf GitHub zur Verfügung gestellt. Nur für den Fall, dass das außer mir noch irgendwo auf der Welt irgendjemand nutzen möchte…

Gerard Meszaros: xUnit Test Patterns

Gerard Meszaros: xUnit Test Patterns
Gerard Meszaros: xUnit Test Patterns

457 Seiten ausschließlich über Unit Test Pattern zu schreiben sind eine Leistung. Und die Pattern sind gut!

Meszaros‘ Buch hat mit über 900 Seiten einen Umfang, der viel Softwareentwickler zurückschrecken lässt. Aber es ist absolut lohnenswert, sich mit dem Thema Test Pattern zu beschäftigen. Der Autor betrachtet Unit Tests in seinem Buch hauptsächlich aus der Perspektive des Refactorings, die Pattern sind aber nicht nur dafür nützlich.

Das Buch ist in fünf Teile gegliedert. In der Einführung wird neben obligatorischen Begriffserklärungen sehr gut dargestellt, welchen Wert automatisierte Unit Tests für Softwareprojekte haben. Meszaros liefert hiert eine nicht zu unterschätzende Argumentationshilfe für viele Projekte.

Der erste Teil des Buches, mit The Narratives schon fast ironisch betitelt, führt den Leser auf 180 Seiten in die Methodik des automatisierten Testens mit Unit Test Frameworks ein. Dabei werden Unit Tests gegenüber anderen Tests abgegrenzt. Methodisch bleibt der Autor aber nicht auf Unit Tests beschränkt, sondern geht z.B. mit Datenbanktests über die klassischen Grenzen des Unit Tests hinaus. Auch wenn das nicht der reinen Lehre des Unit Tests entspricht, hilft es Entwicklern in der Praxis ungemein, sind derartige Vermischungen der Abstraktionsniveaus von Tests in Projekten schlicht und einfach Alltag – und oft auch unvermeidlich.

Im zweiten Teil werden Test Smells vorgestellt – man könnte sie auch als Anti Pattern nennen, aber der Begriff ist einfach zu ausgelutscht. Meszaros nimmt dazu drei Perspektiven ein: Smells des Test Codes, Smells im Testablauf und Smells in Projekten. Alle drei Perspektiven kennen die meisten Entwickler aus ihrer täglichen Arbeit.

Das eigentliche Thema des Buches, Test Pattern, wird im dritten Teil behandelt. Dieser Teil ist zugleich der dickste des Buches. Da der Autor auf der Website zum Buch alle Pattern aufgeführt hat, verzichte ich hier auf eine ausführliche Diskussion einzelner Pattern. Die Pattern sind allesamt sehr ausführlich erklärt, mit Grafiken ergänzt, die eine Vorstellung des Testablaufs einfach machen. Genauso wünscht man sich Diskussionen zu Pattern.

Abgeschlossen wird das Buch durch eine Reihe Anhänge, in denen unter anderem eine ganze Reihe Unit Test Frameworks und andere Tools vorgestellt werden. Verschiedene Verzeichnisse erleichtern die Suche im Buch und ein Glossar, dass es durchaus mit dem Glossary des ISTQB aufnehmen kann, ist auch enthalten.

Fazit: Ein Buch, das jedes Kilo wert ist. Für Softwareentwickler sollte die Lektüre dieses Werkes Einstellungsbedingung sein. Tester sollten es gelesen haben, um zu verstehen, wie leicht Testen sein kann, wenn man die richtigen Werkzeuge und Methoden kennt.

Kent Beck: Test Driven Development by Example

Kent Beck: Test Driven Development by Example
Kent Beck: Test Driven Development by Example

Wer mit Test-Driven Development beginnen möchte, kommt um Kent Becks Buch nicht herum. Es langweilt nicht mit Theorie, wie es laufen sollte, sondern zeigt an drei sehr klaren Beispielen in Java und Python, wie Test-Driven Development funktioniert.

Im ersten Teil wird anhand des berühmten Money-Beispiels gezeigt, wie Test-Driven Development zu gutem Design und klaren Strukturen führt. Dabei entspricht das Ergebnis den Clean Code-Prinzipien, ohne dass man als Entwickler explizit darüber nachdenken muss. Kent Beck zeigt, wie man mit Test-Driven Development Design-Entscheidungen trifft, Refactorings durchführt und den Mut findet, einen Schritt zurück zu gehen, wenn eine Entscheidung sich als nicht mehr optimal herausstellt, weil sich die Anforderungen geändert haben.
Als Sprache für den ersten Teil kommt Java zum Einsatz und – natürlich – JUnit als Framework für die Tests.

Der zweite Teil zeigt am Beispiel von Python, wie man ein xUnit-Framework mit Test-Driven Development erstellen kann. Es lohnt sich, dieses Kapitel zu lesen, wenn man sich eine Vorstellung davon machen möchte, wie Test-Driven Development unter schwierigen Bedingungen funktioniert. Große Kenntnisse in Python sind ebensowenig erforderlich, wie Kenntnisse in Java für den ersten Teil.

Abgerundet wird das Buch mit einem dem Thema Pattern gewidmeten dritten Teil. Sämtliche Pattern werden im Umfeld des Test-Driven Development angewendet, wobei Kent Beck unterscheidet zwischen Test Pattern und Pattern für die Implementierung, die das Testen lediglich vereinfachen. Es ist interessant, dass Kent Beck in diesem Teil z.B. Mock Objects auf ein Pattern reduziert. Eingefleischte Fans von Mock Objects werden sich da sicherlich ungerecht behandelt fühlen, aber aus der Perspektive des Buches ist die Reduzierung an dieser Stelle sicherlich valide. Beispiele für Pattern zur Implementierung sind das Value Object, das Null Object oder die Factory Method.

Für diese und weitere Pattern gibt Kent Beck Empfehlungen dazu, ob sie beim Schreiben von Tests oder beim Refactoring sinnvoller einzusetzen sind. Den Abschluss des dritten Teils bilden Kapitel über Pattern zum Refactoring und zum Meistern von Test-Driven Development.

Der Stil des Buchs ist außergewöhnlich. Kent Beck schreibt, als würde er in einer Pair Programming Session neben einem sitzen. Das irritiert zu Beginn, hilft aber ungemein in das Thema zu finden. Das Buch ist dadurch extrem locker geschrieben und schnell gelesen. Die Code-Beispiele sind sehr gut verständlich.

Fazit: Wer mit Test-Driven Development beginnen möchte, muss dieses Buch gelesen haben. Für Fortgeschrittene ist es zu trivial.

Fragen über Fragen: Test-Werkzeuge in agilen Projekten

Warum testet man Software?
Man will Sicherheit gewinnen, dass die Funktionalitäten, die man realisieren möchte, korrekt umgesetzt sind.

Warum fühlt sich Test Driven Development so gut an?
Es erlaubt, in extrem kurzen Zeitabständen Feedback über die geleistete Arbeit zu erhalten.

Das können, so glaube ich, alle unterschreiben, die in agilen Projekten unterwegs sind.
Fragen über Fragen: Test-Werkzeuge in agilen Projekten weiterlesen

Uwe Vigenschow: Objektorientiertes Testen und Testautomatisierung in der Praxis

Uwe Vigenschow: Objektorientiertes Testen und Testautomatisierung in der Praxis
Uwe Vigenschow: Objektorientiertes Testen und Testautomatisierung in der Praxis

Uwe Vigenschows Buch über Softwaretests und deren Automatisierung ist eines der besten, das ich bisher zu diesem Thema gelesen habe – wenn nicht sogar das beste schlechthin.

Das Buch ist in vier Teile gegliedert, wobei der erste eine angenehm kurze Einführung in die Thematik darstellt und wesentliche Gründe für Softwaretests aufzählt. Danach geht’s gleich ans Eingemachte, im zweiten Teil „Verfahren des Softwaretests“ werden Lösungen für technische (Compiler-Warnungen, Typprüfung, Debugging), analytische (Testdaten und Testfälle ableiten) und methodische (Code-Reviews, Finden guter Testdaten, Überdeckungen) Probleme gezeigt. Daran schließen sich noch zwei Kapitel über das Testen objektorientierter Software (speziell die Probleme mit Vererbung und Assoziationen) und organisatorische Abläufe beim Testen (TDD, Refactoring) an.

Der dritte Teil widmet sich der praktischen Umsetzung, insbesondere der Automatisierung von Tests mit verschiedenen xUnit-Frameworks.

Im vierten und letzten Teil geht der Autor auf die Besonderheiten von Echtzeit- und eingebetteten Systemen ein (dieses Kapitel habe ich nicht gelesen) und die Einführung von Testprofilen als Element der UML 2.

Anhänge mit Beispielimplementierungen in verschiedenen xUnit-Frameworks und einer Übersicht objektorientierter Testmuster runden das Buch ab.

Mein Fazit: Selten lesen sich Fachbücher so angenehm, insbesondere bei der trockenen Thematik des Softwaretestens. Das Buch bringt zwar wenig zur Theorie – der ganze Gegensatz zum Perry – aber genau das macht es für jemanden, der praktisch mit Softwaretests arbeiten will zu einer schnellen Einführung und einem guten Rategeber.

Website zum Buch