Balder ist ein Python-Test-Framework unter MIT-Lizenz, das abstrakte Testlogik von der konkreten Implementierung trennt. Dieselben End-to-End-Tests laufen damit auf mehreren Produktvarianten, etwa einem Brustgurt-Sensor und einer Uhr, ohne doppelten Testcode. Ändert sich ein Protokoll oder ein Sensor, wird nur die Implementierung getauscht, der Test bleibt unverändert.
Das Wichtigste in Kürze
- Bewährte Testframeworks stoßen bei Produktvarianten an Grenzen, weil der Kern der Funktionen gleich bleibt, aber jede Variante ein Protokoll oder eine Schnittstelle ändert.
- Im Python-Test-Framework Balder heißt die abstrakte Testlogik Szenario und die Implementierung Setup; welches Setup zu welchem Szenario passt, ermittelt ein eigener Matching-Algorithmus.
- Balder baut nicht auf Pytest auf, weil Pytest dieses Matching nicht kennt. Das Framework ist deshalb von Grund auf und ohne Dependencies gebaut.
- BalderHub-Pakete liefern nach dem Vorbild von Docker Hub fertige Tests und Features, etwa für Selenium, Page-Objekte, CRUD-Datenmodelle, REST und das Django-Admin-Interface.
- Max Stahlschmidt entwickelt Balder bisher weitgehend allein und sucht Contributor; rund 30 BalderHub-Projekte liegen auf GitHub, viele davon noch im Beta-Zustand.
Ein Python-Test-Framework gegen das Variantenproblem
Balder ist ein Open-Source-Python-Test-Framework, das Max Stahlschmidt für eine Situation gebaut hat, die im Embedded-Testing zum Alltag gehört: Ein Hersteller bringt mehrere Produktvarianten heraus, die einen großen Satz gleicher Funktionen teilen, und trotzdem ändert sich von Variante zu Variante etwas. Ein neues Protokoll kommt hinzu, eine Schnittstelle fällt weg, eine Funktion wird optimiert. Der Kern bleibt gleich, die Tests müssen aber jedes Mal angefasst werden.
Max hat in seiner früheren Arbeit versucht, das in der Testautomatisierung mit bewährten Testframeworks abzubilden, also Testelemente so zu bauen, dass sie sich über Varianten hinweg wiederverwenden lassen. Das ging bis zu einem Punkt und dann nicht mehr. Aus dieser Grenze ist Balder entstanden.
Die Grundidee in einem Satz: Ein Test beschreibt, was geprüft wird, aber nicht, womit. Die Technik dahinter, das Protokoll, das konkrete Gerät, steckt in einer austauschbaren Schicht. Ändert sich das Protokoll, wird nur dieser Teil getauscht, der Test bleibt.
Wie trennt Balder Testlogik und Implementierung?
Balder trennt die abstrakte Testlogik, in Balder Szenarien genannt, von der Implementierung, den Setups, und bringt beides zur Laufzeit über einen eigenen Matching-Algorithmus zusammen. Ein Szenario beschreibt, was ein Test braucht: etwa ein Gerät, das einen Herzimpuls aussendet, ein zweites, das ihn liest, und eine Verbindung zwischen beiden. Der Test selbst hängt am Szenario und ruft nur abstrakte Funktionen auf. Ein Setup beschreibt, was tatsächlich da ist, und weist den einzelnen Features der Geräte ihre Implementierung zu.
„Im Szenario definierst du, was brauche ich, um diesen Test auszuführen. Im Setup schreibe ich rein, was habe ich. Und dann tut Balder später automatisch das Mappen.“
(Max Stahlschmidt)
Ein einfacher Fall macht das greifbar. Ein Simulationsgerät schickt ein Signal raus, ein Lesegerät nimmt es entgegen, der Test vergleicht beide Werte und prüft, ob die Abweichung in der Toleranz liegt. So weit ist noch nicht festgelegt, mit welcher Technologie das passiert oder was das Gerät überhaupt ist. Der Test existiert trotzdem schon. Erst die Implementierung füllt die abstrakten Funktionen für den konkreten Anwendungsfall. Durch diese Abstraktion bleibt derselbe Test wiederverwendbar und lässt sich zugleich an jeder Stelle individuell ausprägen.
Für mehrere Produkte bleibt man dabei im selben Projekt und ruft unterschiedliche Varianten auf. Wer es größer braucht, lagert Tests in eigene Packages aus. Duplizierten Testcode gibt es in beiden Fällen nicht, auch nicht bei drei oder mehr Produkten.
Rund 100 End-to-End-Tests vom Brustgurt auf die Uhr, zwei Features getauscht
Der Nachweis lief als Pilotprojekt mit Sport-Herzfrequenzsensoren verschiedener Hersteller, den Brustgurten, die man beim Joggen trägt. Max und seine Kollegen bestellten die Geräte und testeten sie End-to-End. Für den ersten Sensor entstanden die Tests von Grund auf. Der konnte Bluetooth und sonst kein weiteres Protokoll. Der zweite Sensor unterstützte zusätzlich ANT+, ein im Sportbereich verbreitetes Protokoll. Mit Balder ließen sich die bestehenden Tests, etwa die zur Messgenauigkeit, auf ANT+ portieren und der komplette Test-Satz weiterverwenden; angepasst wurde nur, was sich im Feature-Set geändert hatte.
Der härtere Fall kam mit der Uhr. Ein Brustgurt misst den elektrischen Impuls über Elektroden, eine Sportuhr misst optisch. Rund 100 End-to-End-Tests simulierten bis dahin einen Puls als elektrisches Signal über einen Funktionsgenerator. Ein Produkt, das fachlich genau dasselbe kann, hätte in einem klassischen Aufbau alle 100 Tests zum Umbau gezwungen. In Balder sind es zwei Features.
| Produkt | Was anders ist | Was in Balder angefasst wurde |
|---|---|---|
| Brustgurt 1 | Bluetooth, kleines Feature-Set | Tests neu geschrieben |
| Brustgurt 2 | zusätzlich ANT+ | Tests auf ANT+ portiert, Anpassungen nur im geänderten Feature-Set |
| Sportuhr | optische statt elektrischer Messung | zwei Features neu implementiert, rund 100 Tests unverändert übernommen |
Das erste Feature heißt sinngemäß „simuliere mir das Herz“. Seine alte Implementierung erzeugte ein elektrisches Signal per Funktionsgenerator, die neue simuliert Licht. Das zweite Feature betrifft das automatische Ein- und Ausschalten beim Anlegen und Abnehmen. Beim Funktionsgenerator genügt es, das Signal abzuschalten; bei der optischen Messung muss der Test Umgebungslicht simulieren, damit das Gerät erkennt, dass es abgenommen wurde. Diese beiden Implementierungen wurden ausgetauscht, der Rest der Tests lief auf dem neuen Gerät durch.
Warum wurde Balder nicht auf Pytest aufgebaut?
Weil Pytest dieses Matching zwischen Szenario und Setup nicht kennt und sich dafür zu weit hätte zweckentfremden lassen müssen. Die Idee, auf Pytest aufzusetzen, stand am Anfang durchaus im Raum. Das Ergebnis wäre nach Max’ Einschätzung unübersichtlicher und schwieriger geworden, und in die Pytest-Plugin-Welt hätte es sich wegen des völlig anderen Aufbaus ohnehin nicht einfügen lassen. Balder ist deshalb ein Python-Test-Framework ohne Abhängigkeiten, von Grund auf gebaut und autark einsetzbar.
Die Kehrseite dieser Entscheidung: Testfälle leben im Balder-Umfeld. Weil ein Testfall nur abstrakte Dinge aufruft, die Balder erst zur Laufzeit zusammenführt, lassen sie sich kaum in andere Systeme portieren. Das ist auch nicht das Ziel. Wer Balder nutzt, nutzt dieses System als Ganzes.
Nach außen ist die Architektur dagegen offen. Balder steht unter MIT-Lizenz und hat eine Plugin-Engine, über die sich beliebige Erweiterungen anschließen lassen. Für das Reporting gibt es derzeit ein JUnit-Plugin; alles, was mit JUnit-Dateien geht, geht damit. Weitere Anbindungen sind in Arbeit, für andere Werkzeuge schreibt man bis dahin ein eigenes Plugin. Max sagt selbst, dass die Plugin-Engine noch nicht so ausgebaut ist wie bei Pytest, die wichtigsten Anschlüsse aber bereits einfach gehen.
Eignet sich Balder neben Embedded auch für Webtests?
Ja, das Framework ist von der Domäne her offen, auch wenn es ursprünglich für Embedded entwickelt wurde. Den Anstoß für den Webbereich gaben Kunden von Max’ Firma, die dort unterwegs sind. Theoretisch musste es gehen, praktisch fehlten die Pakete, die die eigentlichen Testfunktionen übernehmen. Die Arbeit der letzten Monate galt deshalb hauptsächlich dem Web.
Für Browser gibt es ein Paket für Selenium, eine Abstraktionsschicht über der Browsersteuerung; ein Tausch gegen Playwright wäre denkbar, aktuell gibt es nur Selenium. Ein HTML-Paket erlaubt Page-Objekte, in denen man ein div-Element mit seinem Selektor benennt und dann anspricht, ohne sich weiter um Selenium zu kümmern. Den größten Nutzen sieht Max im CRUD-Paket (Create, Retrieve, Update, Delete) zusammen mit dem Data-Paket. Dort definiert man Datenmodelle, etwa einen Benutzer mit Vorname und Nachname, legt fest, welche Felder optional sind und welche ein String sein müssen, und bekommt Testlogik und Verifizierung mitgeliefert.
Der Ablauf sieht dann so aus: Über das REST-Paket, bei dem die Features zum Lesen und Schreiben schon fertig sind, wird ein Objekt angelegt. Für das eigene Frontend schreibt man ein Feature, das die Daten aus dem Page-Objekt zurückliest. Balder probiert anschließend die Tests durch, etwa ob Pflichtfelder die passenden Fehlermeldungen liefern. Zu schreiben bleibt nur die Schnittstelle, die an der eigenen Applikation individuell ist. Was Max bisher an Webanwendungen vor sich hatte, ließ sich fast vollständig mit diesen Paketen abdecken. Im Web hält er den Ansatz für genauso sinnvoll wie im Embedded-Bereich, nur dass dort das Variantenproblem drängender ist.
BalderHub: fertige Testpakete nach dem Vorbild von Docker Hub
BalderHub-Pakete sind vorgefertigte Tests und Features, die man in Balder einbindet und nur noch konfiguriert. Die Idee folgt Docker Hub: Was andere schon gebaut haben, zieht man sich dazu. Rund 30 solcher Projekte liegen neben Balder selbst auf GitHub.
Ein Beispiel ist das Paket für das Admin-Interface von Django. Weil dieses Interface vorgefertigt ist, gibt es dafür fertige Features. Wer es testen will, konfiguriert nur noch, was passieren soll. Beim Bau dieses Pakets hat Max KI eingesetzt, konkret, um die vielen Selektoren herauszusuchen. Die Engine von Balder dagegen ist nach wie vor Handarbeit, ohne KI-Agenten.
Auf der Embedded-Seite existieren Pakete für Funktionsgeneratoren und für Oszilloskope. Viele BalderHub-Pakete sind allerdings noch im Beta-Zustand, ihnen fehlt ein Teil dessen, was man zusätzlich bauen müsste.
Ein Framework, das Mitentwickler sucht
Balder ist offiziell seit weniger als einem Jahr veröffentlicht, entwickelt wird es deutlich länger, und das meiste davon hat Max allein gemacht. Ein paar Leute nutzen es aktiv, am Kern oder an Hub-Paketen mitentwickelt hat bisher kaum jemand. Genau das ist sein Wunsch an Leute mit Lust auf Open Source: Hub-Projekte bauen oder direkt am Kern mitarbeiten. Beides liegt offen auf GitHub.
Die nächsten Monate haben eine klare Reihenfolge. Zuerst sollen die Beta-Pakete fertig werden. Für Embedded steht ein Paket für Logic Analyzer an, damit sich beliebige Kurven und Abfolgen aus Balder heraus senden und wieder gegenlesen lassen. Für das Web sind fertige Pakete für verbreitete Frameworks wie Django Admin geplant, weil bei solchen Anwendungen alles vorgegeben ist und ein einmal gebautes Testpaket parallel mitgepflegt werden kann. Wer darauf aufsetzt, dockt sofort an und spart sich das eigene Schreiben. Die Liste dahinter ist länger, als ein Einzelner sie abarbeitet, sagt Max selbst.
