Content tagged tests

Worin ich mich 2016 verbessere: Clojure und Softwaretests

posted on

Mein einer Vorsatz für dieses Jahr ist es die Philosophie von Clojure zu denken. Seit 2011 spiele ich mit Lisp und 2014 hatte ich meinen ersten Kontakt zu Clojure, einem der Dialekte von Lisp. Der andere ist, ich möchte meine Erfahrungen mit Softwaretests ausbauen. Bisher hatte ich vor allem an meinen Fähigkeiten mit Unit-Tests gearbeitet und hierfür meinen Stil gefunden. Jetzt will ich automatische Integrationstests in mein Standardrepertoire von Entwicklungstechniken aufnehmen.

Jetzt im Mai?

Du kennst es bestimmt: an Silvester hast du gute Vorsätze für das neue Jahr und ab Neujahr ist es schwer diese einzuhalten. Die letzten Jahre bin ich gut damit gefahren mir nichts konkretes vorzunehmen, stattdessen ist mein Ziel etwas neues zu erreichen. Das heißt Anfang des Jahres bin ich noch auf der Suche was in diesem Moment das richtige für mich ist. Ich probiere verschiedene Dinge und experimentiere damit. Merke ich, dass es nicht das richtige ist, so muss ich nicht mit meinem Vorsatz brechen, sondern mache mich auf die Suche nach etwas anderem.

Für dieses Jahr bin mir inzwischen sicher, dass ein großes Thema für mich ist, dass ich in den beiden genannten Gebieten mehr Erfahrung sammeln will.

Lisp/Clojure

Web Deelopment with Clojure

Funktionale Programmierung fasziniert mich seitdem ich im ersten Semester an der TUM davon gehört habe. Auch wenn mein täglicher Berufsalltag objektorientiert ist, schreibe ich in diesem Rahmen funktional: Seiteneffekte wo nicht nötig vermeiden, bevorzugt verwende ich unveränderliche Value-Objekte und genieße wie ich in Java8 mit Streams ausdrücken kann was ich mit Daten machen möchte und nicht sagen muss, wie das geschehen soll.

Zu kämpfen habe ich noch damit herauszufinden wie ich ohne Klassen meine Programme auf höherer Ebene möglichst sauber strukturiere. Ich merke den Vorsprung, den die objektorientierte Denkweise in meinem Kopf hat: was ich in Java schreibe hat einfach noch die schönere Globalstruktur, es gelingt mir besser zusammen zu halten was zusammen gehört („high cohesion“) und getrennte Konzepte getrennt zu halten („loose coupling“). Ich denke, es liegt daran, dass ich schon deutlich mehr gute Beispiele für OOP als für funktionale Programme gesehen habe.

Clojure Applied

Vorwärts gebracht haben mich hier dieses Jahr bisher vorallem die Bücher Web Development with Clojure von Dmitri Sotnikov und Michael Swaine am Beispiel von Webanwendungen und Clojure Applied von Alex Miller und Ben Vandgrift für allgemeine Clojure-Programme. Nun muss ich in der Praxis probieren was ich gelesen habe. Hierzu schreibe ich ein Tool das ich brauche gerade als Clojure-Webanwendung. Mal schauen wie ich mit dem Ergebnis zufrieden sein werde …

Service- und Akzeptanztests

Nachdem ich meine Muster für Unittests mit jUnit, Hamcrest und Mockito gefunden habe arbeite ich jetzt daran die richtigen Werkzeuge und Muster für Tests auf höherer Ebene zu finden. Schon vor einiger Zeit hatte ich mit Fit einige Versuche unternommen. Inzwischen ist dieses Werkzeug Teil von FitNesse geworden. Tests werden hierbei in HTML-Dateien geschrieben. Diese können wahlweise zum Beispiel auch in Word oder einem Wiki erstellt werden. „Richtig“ fühlt sich das für mich bisher aber nicht an. Seit ein paar Monaten experimentiere ich stattdessen mit Cucumber. Die Tests werden dabei in (einigermaßen) natürlicher Sprache geschrieben und in einem Textdokument abgelegt. Für mich als Entwickler fühlt sich das sehr viel besser an.

In Fit wird damit argumentiert, dass ein Kunde/Auftraggeber besser in der Lage sei eine Spezifikation zu editieren, wenn er dies in seiner gewohnten Textverarbeitung tun kann. Ich denke aber, dass es immer ein Wunsch bleiben wird, dass man als Entwicklungsteam eine fertige Spezifikation erhält. Es ist wichtiger ein Tool in der Hand zu haben, das es mir ermöglicht mit dem Kunden/Auftraggeber zusammen dies zu erarbeiten. Das ist aber genauso in einem Texteditor möglich. Wichtig ist vielmehr, dass der Kunde ein Verständnis dafür hat, was niedergeschrieben wird. Hierfür eigent sich Gherkin, die Sprache von Cucumber, ausgezeichnet: die Spezifikation kann er als normalen Text lesen.

Mein Weg zur testgetriebenen Entwicklung

posted on

Testgetriebene Entwicklung (TDD) funktioniert – überall. Sie scheitert nicht am Kunden, den nicht Qualität sondern Tempo interessiert. Sie steht nicht im Widerspruch zum jungen Projekt mit wenig Budget, das schnell Kunden gewinnen muss um zu überleben. Sie hindert nicht daran schnell Features umsetzen zu können. Ja, sie macht mir auch nicht (mehr) langsamer.

Es ist keine neun Monate her, dass ich das nicht glauben konnte. Mehrere Anläufe hatte ich unternommen neben Code auch Tests zu schreiben. Länger als zwei Monate ging das nie gut:

Die entscheidenden Hinweise

Test-Driven Development by Example, Kent Beck

Zwei mal klick hat es in meinem Kopf gemacht als ich das Buch „Test Driven Development by Example“ von Kent Beck gelesen habe:

  1. TDD einzuführen ist keine Entscheidung des Kunden, Chefs oder Teams. Das kann jeder für das was er macht selbst tun. Es ist einfach ein Stück persönlicher Programmierstil. Wie ich entscheide, ob ich mir erst auf ein Blatt Papier skizziere was ich programmiere, kann ich auch entscheiden das erst in einem Test zu skizzieren.
  2. Ich hatte davor versucht mit Unit-Tests mehr zu erreichen als ich sollte. Es reicht wenn ich prüfe, dass meine Klasse (Unit) ihre Funktion erbringt und die erwarteten Ergebnisse liefert. Es war falsch zu prüfen, ob mehrere Klassen sich zusammenfügen lassen und gemeinsam richtig arbeiten. Für diese Dinge gibt es Integrations- und Akzeptanztests. Mein Unit-Test stellt nur sicher, dass ich keinen Sonderfall vergesse und sich bei einem Refactoring meiner Klasse (Unit) nichts im Ergebnis ändert.

Mir war klar geworden, dass nicht die Beispiele mit JUnit zu simpel sind, die in fast allen Java-Büchern zu finden sind. Vielmehr war das was ich als Unit betrachtet habe zu komplex. Der Fehler lag nicht in den Beispielen sondern bei mir. Ich hatte meine Probleme nicht so sehr in kleinere Probleme zerlegt, dass sie einfach zu testen sind.

Die ersten sieben Monate

Ein gutes halbes Jahr entwickle ich nur noch testgetrieben. Den Umstieg habe ich geschafft, ich kann mir nicht vorstellen nochmals in die Zeit davor zurückzufallen. Nach einigen Monaten Umstellung habe ich nicht mehr langsamer entwickelt als ohne Tests. Wie bei jeder neuen Technik musste ich am Anfang lernen sie einzusetzen. Das kostet die ersten Wochen und Monate zusätzlich. Dennoch war der Aufand auch damals nicht so hoch wie ich zuvor dachte.

Warum kostet es mich jetzt keine zusätzliche Zeit mehr? Zuerst Tests zu schreiben ist nun eine Struktur in der ich mir Gedanken mache was ich schreiben möchte. Das musste ich auch zuvor tun indem ich Skizzen gemalt, einen Prototypen gebaut oder auch nur Code geschrieben habe, den ich nochmals ändern musste.

Ohne Zusatzaufwand bekomme ich aber die folgenden Dinge frei Haus geliefert:

Was mir sonst noch geholfen hat

Weniger Schlecht Programmieren, Kathrin Passig und Johannes Jander Becoming a Better Programmer, Pete Goodliffe

Zwei Bücher aus den Weihnachtsferien haben meinen Entschluss nur noch mit Tests zu entwickeln gestärkt. In „Weniger schlecht programmieren“ und „Becomming a Better Programmer“ ist mir klar geworden, dass die Professionalität der Entwicklung meine Aufgabe als Entwickler ist. Ich bin der Profi in diesem Bereich und nicht die Geschäftsführung. Diese hat mich dafür angestellt professionell zu arbeiten. Sie verlässt sich darauf, dass ich weiß was notwendig ist und ich dies tue. Wenn ich ihr den Eindruck gebe, es geht auch ohne, wenn es mal sein muss, dann ist klar, dass sie das bevorzugt. Wenn ich der Überzeugung bin, dass es der falsche Weg ist, dann muss ich das vermitteln und darf nicht auf andere schieben, dass es „bei uns“ eben nicht anders geht. Würde ich gegen mein besseres Wissen arbeiten, so hätte zuerst ich versagt und nicht das Management.

Clean Code, Robert C. Martin

Ebenso hat mich der Klassiker „Clean Code“ auf meinem Weg weiter gebracht. Einerseits weil ich durch die Tests erst einiges daraus richtig umsetzen konnte. Vorallem aber weil ich damit gelernt habe auch meine Tests so zu schreiben, dass sie lesbar sind, jederzeit geändert und erweitert werden können.


Unless otherwise credited all material Creative Commons License by Matthias Wimmer