XP-Days 2006 in Hamburg

In diesem Jahr finden die XP-Days in Hamburg statt. Sie werden dieses Jahr zusammen von Andrena und it-agile ausgerichtet. Nähere Infos zum Einreichen von Beiträgen gibt es unter http://www.xpdays.de.

Post bewerten

Korrektur zu GroUnit: JUnit ohne Bytecode

Dierk König wies mich darauf hin, dass mein erstes Argument für GroUnit im Gegensatz zu JUnit so nicht stimmt . Mit groovy.util.AllTestSuite kann man sehr wohl in JUnit auch direkt Groovy-Quellcode testen, ohne diesen vorher nach Bytecode zu compilieren.
Vielen Dank an Dierk für die Klarstellung.

Post bewerten

GroUnit: Unittests mit Groovy

Ursprünglich als reine Fingerübung gedacht, habe ich ein Unittest-Tool für Groovy geschrieben: GroUnit. Das ist nicht weiter schwer, weil Groovy bereits Unterstützung für Unit-Tests mitbringt, allerdings ohne UI. Man kann wg. der nahtlosen Groovy-Java-Integration JUnit auch für Groovy verwenden (siehe z.B. Groovy-Web). Das hat aber ein paar Nachteile:

• Man muss die Groovy-Klassen nach Bytecode compilieren. Für Produktionscode ist das OK, aber während der Entwicklung verlängert es unnötig die Turn-Around-Zeiten.


• Wenn ein Test fehlschlägt, bekommt man im Stack-Trace auch die ganzen Core-Reflection-Geschichten angezeigt, die Groovy im Hintergrund durchführt. Dadurch muss man immer erst mal eine Weile im Stacktrace suchen, bis man das eigentliche Problem überhaupt gefunden hat.


• Seit JUnit 4.0 bringt JUnit keine eigene Benutzungsoberfläche mehr mit. Diese wird von den Entwicklungsumgebungen gestellt. Das ist für Jave wunderbar. Es erzwingt für Groovy aber, dass man eine schwergewichtige Java-Entwicklungsumgebung verwendet. Häufig wäre man mit einem mächtigen Editor besser bedient.

Ich habe versucht, in GroUnit diese Probleme zu adressieren. Sehr weit bin ich in der ersten Version 0.1 sicher noch nicht gekommen. Aber vielleicht engagieren sich noch weitere Leute für GroUnit und es wird noch was richtig Gutes.
Zur GroUnit-Homepage mit Download-Möglichkeit.

Post bewerten

Groovy im Vergleich zu Java am Terminplaner-Beispiel

Ich habe den Terminplaner, den ich als Beispiel für testgetriebene Entwicklung programmiert hatte, von Java auf Groovy migriert. Für den Terminplaner in Java hatte ich testgetrieben ca. 180 Minuten benötigt. Für die Migration nach Groovy habe ich dann ca. 60 Minuten investiert.

Der erste Unterschied der Groovy-Lösung zur Java-Lösung ist der Wegfall der Klasse TeilnahmeStatus (war Enum bei Java). Die Teilnahme-Status-Informationen landen bei Groovy einfach in der Klasse Teilnahme.

Die equals- und compareTo-Methoden sind in Groovy einfacher zu implementieren, weil es für beides eigene Operatoren (== und <=>) gibt, die mit Null-Werten umgehen können.

Bei einer der compareTo-Methoden habe ich bei der Migrationen einen Fehler gefunden, der im Groovy-Code sofort offensichtlich wird. Im Java-Code kann man den Fehler durch die Klammerung beim flüchtigen Lesen übersehen (ist mir beim Schreiben der Java-Lösung ja offensichtlich auch passiert).

Die betroffene Java-Zeile sieht so aus:

int startZeitCompare = startZeit.compareTo(startZeit);

In Groovy wird der Problem sofort offensichtlich:

int startZeitCompare = startZeit <=> startZeit

Es muss natürlich heißen:

int startZeitCompare = startZeit <=> o.startZeit

Die Zahlen nach der Umstellung lesen sich so:

Java-Zahlen

• 5 Fachklassen, 1 Exception-Klasse, 1 Testklasse
  
• 37 Methoden inkl. Konstruktoren + 10 Methoden in Testklasse
  
• 246 LOC operativ + 144 LOC für Testklasse (inkl. Leerzeilen)
  
• 4 For-Schleifen, 4-If-Abfragen
  

Groovy-Zahlen

• 4 Fachklassen, 1 Exception-Klasse, 1 Testklasse
  
• 30 Methoden inkl. Konstruktoren + 9 Methoden in Testklasse
  
• 203 LOC operativ + 123 LOC für Testklasse (inkl. Leerzeilen)
  
• Alle 4 For-Schleifen wurden durch Closures ersetzt, die 4-If-Abfragen blieben bestehen.

Die Code-Ersparnis lässt sich im Wesentlichen auf folgende Groovy-Konzepte zurückführen:

• Closures machen For-Schleifen überflüssig und sind kürzer aufzuschreiben.
  
• Durch Properties werden Getter und Setter überflüssig.
  
• Typecasts entfallen.
  
• In den Tests spart die Uniformität von Arrays und Collections Konvertierungen.

In Groovy habe ich also ca. 80% der LOC (Lines of Code) benötigt, die ich für die Java-Lösung benötigte. Das hört sich erstmal nicht nach einem Quantensprung an. Allerdings muss man bedenken, dass ich „lediglich“ Java durch das doch sehr ähnliche Groovy ersetzt habe. Also hat eine Einzelmaßnahme 20% Code-Ersparnis gebracht. Setzt man das einfach mal naiv mit 20% Kostenersparnis gleich, ist man sehr schnell in Regionen, die interessant erscheinen (die meisten Offshoring-Untersuchungen sprechen von geringeren Einsparungspotenzialen).

Außerdem ist zu bedenken, dass mein Terminplaner-Beispiel die Strukturen in den Vordergrund stellt und die Daten ignoriert (so hat der Benutzer nur seinen Namen und der Termin nur 4 Datenfelder). In einer vollständigen Terminplaner-Anwendung sind viel mehr Datenfelder zu verwalten (MS-Outlook hat für Kontakte so um die 30 Datenfelder). Und gerade wenn es nur um das Halten von Datenfeldern geht, spielt Groovy seinen LoC-Vorteil aus. Die 30 Datenfelder würden in Groovy ca. 10 LoC bedeuten und in Java ca. 130 LoC (beide Zahlen inkl. Leerzeilen).

Nicht zuletzt habe ich die Terminplaner-Anwendung relativ stumpf auf Groovy umgestellt. Ich muss prüfen, ob sich der Code durch fortgeschrittene Groovy-Konzepte noch weiter vereinfachen lässt.

Der Groovy-Code findet sich hier zum Download.

Post bewerten