Mocking

Der Umfang eines Systemtests läuft schnell aus dem Ruder, wenn er versucht, auch noch alle Subsysteme einer Anwendung abzudecken. Der Admin muss dann jeden fehlgeschlagenen Einzeltest aufwändig untersuchen, um herauszufinden, ob der Fehler in einem Subsystem steckt oder in einer der letzten Änderungen.

Mocking ist ein gängiges Verfahren, um einen Systemtest präziser auf die eigene Anwendung zuzuschneiden. Es ersetzt alle für den Test irrelevanten Bestandteile der Anwendung durch sich ähnlich verhaltende, aber funktional nutzlose Komponenten. Diese laufen meist lokal auf demselben Server mit, um die externen Abhängigkeiten möglichst zu reduzieren. Gutes Mocking ersetzt im Test die externe Datenbank durch eine lokale, die exakt definierte Inhalte verwaltet. Oder es wechselt einen externen Anmeldedienst gegen eine lokale Version aus, die immer nur mit “Ja” antwortet.

Schon in der Designphase eines Softwareprojekts sollte sich der Entwickler Gedanken über dessen Eignung für Tests machen. Indem er die unterschiedlichen funktionalen Einheiten geschickt voneinander trennt, kann er sie später besser testen und einfacher geeignete Mocks erstellen. Dahinter steckt die Idee, alle Probleme möglichst klein zu schneiden und sie damit überschaubar zu machen. Denkt der Entwickler erst ans Testen, wenn er den Code bereits umsetzt, macht er es sich wesentlich schwerer. Zwei Beispiele zeigen den Umgang mit Mocking in der Praxis.

Beispiel 1: SAN-Mountservice

Der SAN-Mountservice verwaltet dauerhaften Speicher (persistent Storage), den die bei Immobilienscout24 installierten Systeme verwenden. In der Praxis sieht es so aus, dass alle eingesetzten Linux-Systeme einen Systembereich und bei Bedarf einen Datenbereich erhalten. Da der Installationsdienst den Systembereich automatisch löscht, sobald er ein neues Linux aufsetzt, muss eine Anwendung den persistenten Datenbereich verwenden, um ihre Daten langfristig zu sichern. Letzterer steht dem System entweder als zweite lokale Festplatte oder auch als SAN LUN zur Verfügung.

Technisch ist die Lösung relativ einfach: Der SAN-Mountservice hängt alle Dateisysteme mit einem Label nach dem Schema »persist:/Pfad« in den entsprechenden »/Pfad« ein. Da dieser Dienst sehr früh beim Booten startet, verlassen sich die Anwendungen auf den Persistenzspeicher.

Auch der SAN-Mountservice liegt in Form von RPM-Paketen vor, die – dem zuvor gezeigten Entwicklungsmodell folgend – Unittests und einen Systemtest durchlaufen. Diese Absicherung erlaubt es, das Paket automatisch bauen zu lassen und es nach erfolgreichen Tests direkt in die Produktion zu schieben. Das damit verbundene Risiko ist durchaus hoch, genügt doch bereits ein einfacher Tippfehler, um in der gesamten Produktion die Datenfestplatten zu deaktivieren.

Mocking im Blockdevice

Der SAN-Mountservice selbst ist ein Bash-Skript, das nur ungefähr 200 Zeilen umfasst. Der Unittest besteht in diesem Fall lediglich aus einem einfachen Syntaxcheck mit »bash -n« . Der entscheidende Test ist der Systemtest, der das neu gebaute RPM-Paket auf einem Testsystem installiert. Das Testskript führt über RSH ungefähr die Schritte aus Tabelle 1 aus. Zusätzlich spielt der Test noch einige typische Fehlerszenarien durch.

Das Mocking findet in diesem Beispiel auf der Ebene des Blockdevice statt. Für den SAN-Mountservice kommt es lediglich darauf an, dass der abgesetzte »blkid« -Befehl [9] ein Blockdevice mit einem passend benannten Dateisystem anzeigt. Wie das Blockdevice im Linux-System hängt, interessiert ihn nicht.