Einstieg in Integration Tests

[buhtz]

Ich versuche herauszufinden, wie man Integration Tests macht bzw. einrichtet, konfiguriert und deren Resultate systematisch auswertet. Den Aspekt grafische Oberfläche können wir hier erst einmal noch weg lassen.
Dabei bin ich mir nicht einmal sicher, ob der Begriff korrekt gewählt ist.

Mir ist auch klar, dass ich hier keine fertige Anleitung bekomme. Ich brauche nur ein paar Begrifflichkeiten und dass mich jemand in die richtige Richtung schubst. Die vage Form meiner Frage, deutet sicher auch darauf hin, dass hier noch viel Nebel für mich ist.

Aus dem Python Umfeld kenne ich unittests und habe diese bereits so verinnerlicht, dass ich ohne gar nicht mehr ruhig schlafen kann.

Befrage ich die Suchmaschine des Vertrauens nach Integration Tests lande ich dennoch häufig bei unittests. Mir ist auch klar, dass man bis zu einem gewissen Grad auch komplexe Funktionsweisen durchaus mit der unittest Technik abdecken kann. Sie nutzen dann zwar Pythons unittest oder pytest Package, aber sind konzeptionell und auch von der Laufzeit her eher integration tests.

Soweit zu meinem "Vorwissen".

Nehmen wir eine Anwendung, die Dateien von A nach B "transferiert"; eine Backup Software. Unter der Haube wird rsync verwendet und dementsprechend sind alle möglichen Protokolle (FTP, SSH, local filesystem, NFS, Samba, ...) und Dateisysteme möglich. Genau diese Kombinationen möchte ich testen. Landen auf B die Dateien und Ordner mit den passenden Rechten und Attributen, so wie ich es erwarte; das ist die Testfrage.

Würde ich das manuell machen, müsste ich viele virtuelle Maschinen (oder Container?) aufsetzen, deren Netzwerk konfigurieren, die Dateisysteme und Uhrzeiten in definierten wiederholbaren Zustand halten usw. Die ganze Config und der initiale Zustand der VMs muss wiederholbar sein usw.

Für den Anfang möchte ich das lokal auf meiner Maschine machen. Ich brauche also keine CI für GitHub, GitLab, Gitea, etc. Ich möchte es erst einmal selbst einrichten, um ein Gefühl dafür zu bekommen und mir nicht alles in einer GitHub Oberfläche zusammen klicken (falls das überhaupt geht). Wenn es unbedingt sein muss, würde ich mir zum Üben auch eine lokale Gitea Instanz einrichten.

[rhHeini]

Komme aus einem industriellen Umfeld wo Teile eines Systems bestehend aus Hardware und Software woanders entwickelt und gefertigt werden. Habe mich in den letzten 25 Jahren damit beschäftigt diese Fremdkomponenten ins System zu integrieren und zu testen.

Integration bedeutet zu schauen ob die Schnittstellen so sind wie gefordert und daß das Zusammenspiel im System funktioniert. Unittest beschreibt dabei HW und SW-Tests die allein mit den Zulieferkomponenten beim Zulieferer durchgeführt werden können. Integrationstest ist der formale Nachweis des Zusammenspiels im System. Dazu gehören zum Teil auch regulatorische Nachweise.

So ist die Definition in einem gemischten Umfeld.

Gruß, Rolf

[paedubucher]

Deine Anforderung klingt für mich eher wie ein kompletter Systemtest. Bei einem Integrationstest testet man das Zusammenspiel verschiedener Komponenten aus der eigenen Codebasis, d.h. nicht nur eine "Unit" im Sinne einer Klasse, sondern wie mehrere Units (Klassen) zusammenarbeiten.

Angenommen, du hast eine Klasse namens CustomerService mit der Methode saveCustomer(Customer c). Diese Methode persistiert das mitgegebene Customer-Objekt auf eine Datenbank, indem Sie die Klasse CustomerPersistor verwendet. Bei einem Unit Test sollte man nun ein Test Double für die Klasse CustomerPersistor schreiben, sodass die Originalklasse nicht mitgetestet wird. (Ein Fehler im Datenbankcode sagt ja nichts über die Güte deines Service-Codes aus.) Beim Integrationstest hingegen testest du bis unten auf die Datenbank durch (i.d.R. mit einer In-Memory-DB für die Testkonfiguration).

Der Unit Test fragt: Funktionieren die einzelnen Klassen?

Der Integrationstest fragt: Spielen die einzelnen Klassen korrekt zusammen?

Sorry für das Java-Beispiel, ich hatte da wohl ein Flashback. Grundsätzlich kann man aber für Unit- und Integrationstests die gleiche Technologie verwenden, z.B. PyTest in Python.

Ich selber verzichte auf Mocking und schreibe darum tendenziell mehr Integrations- als Unittests. Dafür testet man in Python im Gegensatz zu Java nicht nur die öffentlichen Schnittstellen, sondern einfach alle Funktionen per Unit Test.

Bei einem Systemtest kommt in der Regel ein erweiterter Technologiestack zum Einsatz. Das kann z.B. ein Shell-Skript sein, welches deine komplette Software startet.

[buhtz]

Bei einem Systemtest kommt in der Regel ein erweiterter Technologiestack zum Einsatz. Das kann z.B. ein Shell-Skript sein, welches deine komplette Software startet.

Der Begriff Integrationstest ist hier also nicht korrekt?

Ich muss nach Systemtest suchen?

Aber auch dafür gibt es doch sicher Anwendungen und Technologien, um das systematisch und wiederholbar laufen zu lassen und die Resultate eben auch systematisch auszuwerten.

Klar müssen im Hintergrund eine Menge VMs/Container zurückgesetzt und gestartet werden. Solche Test können vermutlich Tage lang laufen, bis sie fertig sind. Am Ende brauche ich dann eine Ausgabe (oder log) in dem eine "N passed. N errors" und möglichst weiterführende Hinweise auf fehlgeschlagene Tests steht. Ich bin doch bestimmt nicht der Erste, der sowas machen möchte.

Soweit ich das bisher absehen kann brauche ich VMs, die einen definierten Dateisysteminhalt incl. Uhrzeit(!) und entsprechende Netzwerkzugriffe zueinander haben. Per Zauberbefehl (von "Außen") wird auf Maschine A die zu testende Anwendung gestartet, erledigt ihre Arbeit und am Ende wird auf Maschine B geschaut, ob dort die "Daten erzeugt" wurden, so wie es der Test definiert hat. Zur Erinnerung: Es geht im Kern darum, Dateien/Daten von A nach B zu "transferieren".

Ich kann mir das schon grob vorstellen, wie man sich sowas selbst strickt, aber ich hoffe das muss nicht sein. Wenn es auf das Selbststricken hinaus läuft, würde ich eine VM/Container Technik benötigen, bei der ich diese von "Außen steuern" kann. Ja, was heißt das jetzt? Systemuhrzeit setzen. Zustand und Inhalt des Dateisystems prüfen. Laufende Prozess prüfen. Bisher habe ich nur mit VirtualBox gearbeitet. Qemu mag mich nicht. Container und LXE hab ich bisher nicht so ganz begriffen, aber darauf würde es wohl hinauslaufen.

Habt ihr evtl. einen Vorschlag in welchen Communities man sich hier noch Ratschläge holen könnte? Für StackOverflow erscheint mir die Frage zu "broad". Ich würde es vielleicht auf der FSFE Mailingliste probieren oder bei Apache, Mozilla, ...? Die müssen doch auch sowas machen.

[paedubucher]

Mal von der Abgrenzung Systemtest/Integrationstest abgesehen: Wenn du mehrere VMs hochfahren willst für einen Test, dann würde ich dir einen Blick auf Vagrant empfehlen. Das spielt gut mit Virtualbox zusammen und kann in Ruby geskriptet werden. Du kannst auch noch Ansible oder ein ähnliches Konfigurationsmanagementtool dranhängen, um die VMs bereit zu machen. Die VMs kannst du auch recht statisch aufbauen, indem du so etwas wie Packer verwendest. Das sind halt jetzt einfach die Technologien, die ich kenne.

Mit Docker und Docker Compose bringst du das Setup aber wohl schlanker und schneller hin. Die Frage ist, ob du es mich "echten" VMs und den darunterliegenden Betriebssystemen testen willst, oder ob Container auch reichen.

Aber selbst das kannst du schlussendlich über dein Unittest-Framework ansteuern, wenn du willst. Ich rate zwar davon ab, da Unittests etwas schnelles sein sollten, aber technisch möglich und erlaubt ist es. So wäre auch gleich das Reporting gelöst.

[buhtz]

Zu Vagrant hatte ich hier (https://discuss.hashicorp.com/t/use-cas ... sion/43749) mal ein konkretes Szenario beschrieben und um Feedback von Vagrant gebeten.

Mir scheint Vagrant ist nicht zum Testen gedacht, weil ein Reporting Mechanismus fehlt.