Naming - in der Literatur
Naming ist ja, glaubt man Phil Karlton, eines der schwierigsten Probleme in der Informatik. Offensichtlich nicht nur da. Zumindest drängte sich mir beim Lesen von G.R.R. Martins Hauptwerk “Das Lied von Eis und Feuer” in deutscher Übersetzung auf, dass hier jemand mit Namen gekämpft hat:
Tiefe Assertions
Gelegentlich hat man es beim Unit-Testen nicht mit einfachen Typen zu tun, sondern z.B. mit
- Ergebnisse von Webservice-Schnittstellen (REST/SOAP)
- ORM-gemappte Datenbank-Ergebnisse
- generierte Parse-Bäumen
- jegliche Art Graph oder Baum
Solche Typen sind oft tief (oder rekursiv) geschachtelt und deswegen nich ganz so einfach zu testen. Mit dem richtigen Werkzeug geht es aber - z.B. mit dem IsEquivalent-Matcher von XrayInterface …
Testgenerierung in Java - eine Übersicht
So langsam möchte ich meine Erkenntnisse über Testgenerierung zusammenfassen. Seit etwa einem Jahr habe ich einen Vortrag über Testgenerierung in Java auf diversen Konferenzen positioniert und inzwischen gibt es so etwas wie eine Essenz aus diesen Vorträgen …
Test-Generatoren - Stand der Technik
Vielleicht interessiert den einen oder anderen eine Übersicht über Testgeneratoren. Eine ziemlich vollständige Liste findet man auf der Zusammenfassung von Zoltán Micskei über Code-based test generation. Die meisten der hier gelisteten Projekte sind eher akademischer Natur und bestenfalls für Beispielcode einsetzbar.
Reguläre Ausdrücke in Java
Unkritisch habe ich Jahre lang reguläre Ausdrücke (java.util.regex) in Java verwendet. Auf der Universität hatte man ja gelernt, dass reguläre Ausdrücke effizient ausgewertet werden können.
Als ich in einem Projekt in einer großen Menge von Dokumenten (>10.000) eine große Menge von Worten (>1.000) suchen wollte, erinnerte ich mich an die Universität. Anstatt jedes Wort einzeln zu suchen wollte ich den regulären Ausdruck <Wort1>|<Wort2>|...|<Wort1000> suchen. Das müsste theoretisch deutlich effizienter sein, als nacheinander alle Wörter in jedem Dokument zu durchsuchen … Aber regulärer Ausdruck ist nicht regulärer Ausdruck und die schnellen Automaten der Vorlesung sind nicht die, die in Java verwendet werden.
Exaktes String Matching in der Praxis
Zunächst war mein Interesse an Textsuchalgorithmen eher akademischer Natur - einfach nur den Algorithmus verstehen und implementieren können. Nachdem aus dieser Leidenschaft ein kleines Projekt (StringSearchAlgorithms) enstanden ist - begann ich Vergleiche anzustellen …
Es stellte sich heraus, dass viele Algorithmen zwar im akademischen Sinne funktionieren, aber in der Praxis erschwert (oder gar nicht) einsetzbar sind. Tatsächlich sind die akademischen Algorithmen für ganz bestimmte Situationen optimiert und sehr spezifisch gebunden an:
- Prozessorarchitekturen
- Encoding-Formaten
- Programmiersprachen (APIs)
Es folgt eine Übersicht über die Herausforderungen, die die Praxis an Textsuche stellt.
Testrecorder – Quo Vadis
Nach meinem Vortrag auf dem Karlsruher Entwicklertag habe ich jetzt auch einmal Zeit ein wenig über die Zukunft von Testrecorder zu reden … Testrecorder ist ein Java-Werkzeug zum Aufzeichnen von Laufzeitsituationen. Ausgehend von einem Methodenaufruf werden der Zustand davor und der Zustand danach aufgezeichnet. Das Ergebnis wird dann als JUnit-Test ausgegeben.
Naming von Interfaces und Implementierungen
Viele kennen vielleicht die Konstellation, dass man zu einem Interface FormDataValue eine Implementierungsklasse FormDataValueImpl vorfindet. Auf meine leicht überhebliche Kritik bekomme ich dennoch oft Zustimmung - und eine Entschuldigung der Form: “Wir haben uns Team-intern gegen Interface-Namenskonventionen wie z.B. IFormDataValue entschieden.”
Da fühle ich mich dann etwas missverstanden. Beim Naming gibt es nunmal mehr Möglichkeiten. Warum kommen manche Teams nur auf diese zwei? Ich versuche das Problem einmal etwas tiefer zu analysieren …
Textsuche in Java (mit der JDK-API)
Textsuche ist eine recht häufiges Problemstellung, die immer dann auftritt, wenn wir prüfen ob ein String in einem anderen vorkommt. Die JDK-Standard-API bietet hier ein paar Grundfunktionalitäten, allerdings gibt es deutlich effizientere Methoden, insbesondere für größere Muster und größere Texte.
Dieser Beitrag könnte für diejenigen von Interesse sein, die sich für Textsuche und die Möglichkeiten der Java-API (bzw. Alternativen darüber hinaus) interessieren.
Private Variablen erreichen mit XRayInterface
In diesem Beitrag möchte ich eine Möglichkeit eröffnen wie man auf private Variablen und Methoden zugreifen kann, indem man seine Klassen an passende Interfaces adaptiert. Warum? In meinem früheren Beitrag über das Reparieren von Legacy Code habe ich kurz erwähnt, dass eine große Herausforderung beim Testen der Zugriff auf den verborgenem Zustand (private Variablen/Felder) vor und nach der Ausführung der Methoden ist.
Reparieren von Legacy-Code – Automatisch
Viele Projekte verwenden bereits automatisierte Regressionstests. Leider ist das genau dann nicht gegeben, wenn man es am nötigsten hat, nämlich bei Übernahme von fremdem (ungetesteten) Legacy-Code. Hier wünsche ich mir nicht nur automatisierte Regressionstests, sondern auch automatisierte Testerstellung. Warum gibt es so etwas nicht?
Meine Präsentationen
Ich habe auf diversen Konferenzen Vorträge gehalten. Eine volle Liste findet man bei Talks.
Meine Projekte
Ich habe diverse Open-Source-Projekte auf Github, meine erfolgreichsten Projekte haben eine eigene Webpräsenz bekommen:
- Testrecorder - Testgenerierung aus typischen Anwendungsmustern
- XRayInterface - Objektorientierte Adapter für private Felder und Methoden
- String Search Algorithms - Sammlung von String-Suchalgorithmen