Gedanken zur agilen Softwareentwicklung
Die Bibliothek Mockito ist für Java Entwickler in der Testerstellung ein unverzichtbarer Begleiter geworden. Leider kann bei der Verwendung von Mock Objekten so mancher Fehler passieren. Einige Anti-Pattern zum Testen mit Mocks wurde dazu im Beitrag Morden mit Mockito besprochen. Häufig werden aber auch nützliche Möglichkeiten von Mockito übersehen und dadurch die Tests unnötig aufgebläht.
Es existiert kaum ein Software Projekt in dem nicht irgendwelche Daten in einer Datenbank gespeichert werden. Solange sich das Projekt im Entwicklungsstatus befindet sind vielfache Änderungen am Datenbankschema kein Problem. Gerade bei der Entwicklung mit Datenbankabstraktionen wie Hibernate oder JPA machen sich Entwickler wenig Gedanken, weil das Framework sich um die Aktualisierung des Schemas kümmert. Spätestens wenn die Software in Produktion verwendet wird, ändert sich dieser gedankenlose Umgang mit den Datenbankstrukturen.
Die Holidays Bibliothek aus dem Beitrag Kalenderspielereien mit Java hat schon seit geraumer Zeit keine Aktualisierung erfahren. Daher sollen einige Methoden hinzuzugefügt werden um den Umgang mit Werktagen zu vereinfachen.
Häufig müssen Daten aus einer Darstellung in eine andere transformiert werden, weil z.B. eine Kopplung von Datenbank Entitäten an einen REST Controller unerwünscht ist. Im Beitrag Hin und Her mit MapStruct wurde der entsprechende Framework vorgestellt. Neben MapStruct und dem unschönen Selbermachen, gibt es aber noch weitere Alternativen. Eine dieser Alternativen ist das ModelMapper Framework. Auch mit diesem Framework können Instanzen verschiedener Klassen aufeinander abgebildet werden und dabei in gewissen Rahmen manipuliert werden.
Die Bibliothek SpringDoc-OpenAPI ist ein gute Ergänzung für die eigene REST API, um die Endpunkte mit einer Dokumentation zu versehen. Die Bibliothek analysiert die @RestController annotierten Klassen und extrahiert Informationen zu Endpunkten, Parametern, Requests, Responses und Fehlercodes. Die gefundenen Informationen werden als OpenAPI Dokumentation im YAML oder JSON Format ausgegeben. Das klingt sehr gut, nur leider funktioniert es nicht ohne zusätzliche Eingriffe der Entwickler.
Als Software Entwickler lernt man immer wieder neue Varianten eindeutiger Kennzeichner kennen. Da gibt es die bekannten Kennzeichner wie die Telefonnummern, Kreditkartennummern, PLZ, ISBN, EAN-13, IATA, IBAN, BIC, die veraltete BLZ und nicht so bekannte wie die internationalen Patentnummern, Kreisgemeindeschlüssel und die Leitweg ID. Alle diese Kennzeichner müssen erkannt, geprüft, interpretiert und geschrieben werden können.
Wer seine Daten in der Persistenzschicht ablegen möchte, hat häufig mit relationalen Datenbanken zu tun. Obwohl Frameworks wie Hibernate und JPA das Hantieren mit lästigen SQL Aufrufen häufig vergessen lassen, muss man hin und wieder schauen, was im Hintergrund geschieht.
Wer technische Dokumentationen erstellen muss, hat mit Asciidoctor eine einfache aber leistungsfähige Lösung zur Hand. Asciidoctor ist ein Textprozessor, der Vorlagen aus einfachen Textdateien in HTML, PDF, EPUB3 oder Docbook Format umwandelt. Durch die Asciidoctor API können dazu noch eigene Erweiterungen integriert werden.
REST Services können nur eine gewisse Anzahl von Anfragen innerhalb eines Zeit Fensters verarbeiten. Werden zu viele Anfragen gestellt, dann gerät der Service unter Last und reagiert sehr langsam oder gar nicht mehr. Zusätzliche Anfragen, die ein vorgegebenes Limit übersteigen, sollten daher vom Service abgelehnt werden.
Mit dem Extension Model von JUnit 5 gibt es Vielzahl neuer Möglichkeiten, das Schreiben von Unit Tests zu vereinfachen. In den Beiträgen Dependency Injection mit ParameterResolver in JUnit 5 und Zufallswerte in JUnit 5 wurde der JUnit 5 ParameterResolver behandelt. Dieser Beitrag stellt den InvocationInterceptor vor.