Warum CheetUnit?
Wie sehen wir den Zweck der Integrationstests? Mit Integrationstests wollen wir überprüfen, dass das System korrekt funktioniert, wenn es auf dem Applikationsserver läuft und an verschiedene Umsystemen und Datenbanken eingebunden ist.
Hätte jedes Service eine öffentliche Schnittstelle (z.B. REST), wäre es einfach: Wir schicken eine Testanfrage an das System und kontrollieren, ob die erwartete Antwort zurückkommt. Mithilfe von Datenbank-Tools (z.B. DB-Unit) lässt sich feststellen, ob der Datenbankstand nach dem Serveraufruf korrekt ist.
Aber wie kann man interne Services testen, welche keine Webschnittstelle haben? Welche Frameworks stehen zur Verfügung?
Karate ist besser für API-Tests geeignet. Cucumber hat eher mit Akzeptanztests zu tun. Arquillian hat in manchen Situationen Nachteile, die das Testen aus unserer Sicht etwas schwieriger machen: Wenn das System groß ist oder aus mehreren Subsystemen besteht, kann der Zusammenbau des Deployments nicht einfach sein. Ein weiterer Nachteil von Arquillian ist die Performance, sobald das Projekt ein größeres Ausmaß annimmt.
Sollten wir lieber Microservices verwenden? Dann ist das Problem gelöst. Wir wissen jedoch, dass es aus verschiedensten Gründen nicht immer möglich ist. Und es gibt auch bestehende Applikationen, die man warten und weiterentwickeln muss. Was könnte man einsetzen, wenn man Tests gegen eine bereits installierte Applikation ausführen will? Wir brauchten so ein Tool. Und nun haben wir CheetUnit!