Agile Coding mit Java, Kotlin, Spring und Microservices

Selenium ist ein bekanntes Framework zum automatisierten Testen von Web-Anwendungen durch den Browser. Selenium automatisiert aber auch gut Prozesse, die mit dem Browser bedient werden. In diesem Artikel stelle ich Selenium anhand eines Browser Klick-Bots vor, der die Begehrtheit von Whiskies berechnet. 🥃 English presentation of this article Selenium und Whisky Beruflich habe ich Selenium, wie die meisten, schon zur Automatisierung von Tests benutzt. Selenium ist ein Tool zur Browser-Steuerung. Deshalb wird es meistens für Ende zu Ende Tests eingesetzt, welche die Web-Anwendung vom Browser ausgehend testen.  Beruflich automatisierte ich mit Selenium auch schon Prozesse, welche durch den Browser bedient werden. Als ich bei meinem Hobby "Zahlen, Daten, Fakten zu Single Malt Whiskies" (nur Trinken kann ja jeder 😉) auf die Idee kam die Whiskybase auszuwerten, fiel mir direkt Selenium als geeignetes Werkzeug ein. Die Whiskybase ist eine von Whisky-Fans getriebene Webseite bzw. O

Services oder Microservices mit REST-API können mit wenigen und einfachen Tools entwicklungsbegleitend getestet werden. Mit dem Spring Boot Standard Technologie-Stack bestehend aus JUnit, Mockito und Maven können EntwicklerInnen direkt loslegen und automatisierte Unit- und Integrationstests schreiben. In diesem Artikel werde ich dies demonstrieren und Tipps zur Integration in eine CICD Pipeline geben. Die Testpyramide bzw. Testarten Wenn ihr nach der Testpyramide sucht, findet ihr relativ viele verschiedene Varianten. Das Prinzip ist aber immer ähnlich: die meisten Tests werden auf der untersten Ebene benötigt, wo die kleinsten Einheiten möglichst umfangreich getestet werden. Das ist typischer Weise die Testart Unit Tests zum Testen von einzelnen Klassen. Je höher man in den Ebenen der Testpyramide aufsteigt, desto weniger Tests werden benötigt, da diese Tests einen deutlich größeren Bereich des Systems durchlaufen. Für Services oder Microservices mit einer REST-API könnte die Testpyra

Automatisiertes Testen von Spring Beans kann anfangs schwierig sein. Daher zeige ich euch in diesem Artikel, wie ihr die typischen Herausforderungen beim Testen von void-Methoden, Datenbank- und Backend-Interaktionen mit Spring Boot und Mockito in den Griff bekommt. Unit-Tests mit dem Mockito Mock-Framework Wenn wir in einer Klasse oder Spring Bean Methoden haben, die eine Datenbank oder die Verfügbarkeit eines Backends benötigen, ist das für Unit-Tests ein Problem. Unit-Tests konzentrieren sich immer auf die kleinste Einheit und die schließt Datenbanken und Backends aus. Um solche Methoden trotzdem Testen zu können, gibt es Mocks. Ein Mock ersetzt die Datenbank oder das Backend und liefert von uns vorbereitete Testdaten zurück. Weitere Infos zu Mocks findet ihr hier: https://de.wikipedia.org/wiki/Mock-Objekt Mockito ist eines der beliebtesten Mock-Frameworks für Java oder Kotlin und bietet eine einfache API zum Erstellen, Konfigurieren und Interagieren mit Mocks an. Daher wird Mockito

Testgetriebene Entwicklung besteht aus 3 Schritten: Rot: Schreib ausreichend viele fehlschlagende Unit Tests. Grün: Schreib nur so viel Code (nicht mehr), dass alle Unit Tests grün sind. Blau: Falls nötig, refaktorisiere den Code und Deine Unit Tests. In diesem Blog-Artikel werde ich das anhand des Clean Code Bowling Game Katas in der Programmiersprache Kotlin mit JUnit Tests demonstrieren. Testgetriebene Entwicklung Ich kenne testgetrieben Entwicklung aus Extreme Programming (von Kent Beck) und Clean Code (von Robert C. Martin). Dort wird der TDD-Zyklus als Entwicklungsprozess in 3 sich wiederholenden Schritten beschrieben. Im folgenden Bild zeige ich den Zyklus mit den entsprechenden Farben, die aus dem Status der Testergebnisse abgeleitet sind. Rot - Test schlägt fehl In der ersten Phase ROT wird mindestens ein neuer Testfall geschrieben oder ein bestehender erweitert. Wichtig ist dabei, dass dieser Testfall dann fehlschlägt, daher die Status Farbe Rot. Es ist auch erlaubt mehrere T

In Corona-Zeiten sind Team-Events rar geworden und trotz Video-Konferenz eher mäßig beliebt. Sicherlich gibt es hier auch schon einige gute Konzepte - ein weiteres Event-Konzept speziell für Software-EntwicklerInnen habe ich im Urlaub entdeckt: das virtuelle Clean Code Dojo. Das Clean Code Dojo Im Buch "The Clean Coder" erklärt Onkel Bob, wie wichtig Training für Software-EntwicklerInnen ist. Teil des Trainings sind natürlich auch alle möglichen Lernkonzepte, wie z.B. Schulungen, Fachbücher, Blogs, Podcasts usw. Er stellt aber auch eine weitere Trainings-Form vor, welche aus dem Kampfsport abgeleitet ist: das "Coding Dojo". In Onkel Bobs altem Blog gibt es dazu ebenfalls einen Eintrag:  http://www.butunclebob.com/ Hier auch noch der Link zum aktuellen Clean Coder Blog:  https://blog.cleancoder.com/ Im Coding Dojo führen die trainierenden SchülerInnen Katas aus, so wie ihr es aus Karate kennt:  Wikipedia Kata . Nur sind diese Katas keine Tritt- und Schlag-Choreografi