Worin ich mich 2016 verbessere: Clojure und Softwaretests
Tagged as DE · Clojure · tests
Written 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
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.
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.