Language-Workbench für Testsprachen

Kennen Sie das? Das Gefühl, all das schon einmal erlebt zu haben? Ein Déjà-vu? Selbiges beschlich mich vergangene Woche bei einem ersten Gespräch mit einem Automobilhersteller über das Tooling seiner hauseigenen Testsprache.

Das Problem ist jedes Mal dasselbe. Schon vor Jahren ist die Erkenntnis gereift, dass es nicht sinnvoll ist, die riesige Menge an Testfällen gegen fast jährlich neue Modelle immer wieder neu zu entwickeln. Jedes Mal wieder Unmengen an Zeit und Geld in die Programmierung zu stecken für Arbeiten, die doch eigentlich schon zig Mal erledigt wurden. Nur eben „ein klein wenig anders“.

Auch die Lösung dieses Problems war grundsätzlich die Richtige: eine eigene, kleine Programmiersprache, um Testfälle zu spezifizieren. Der eigentliche Testcode in C wird dann daraus generiert.

Auf diese Weise können sinnvolle Abstraktionen geschaffen werden, welche für verschiedene Modellserien anpassbar und parametrisierbar sind, ohne sich mit technischen Aspekten wie Zeigerarithmetik und Speicherverletzungen herumzuschlagen.

Doch nach einiger Zeit wurden die Schattenseiten dieses Ansatzes deutlich. Während das Tooling für gängige Programmiersprachen exzellent und ausgereift ist und die Entwickler mit mächtigen Werkzeugen zum Editieren des Codes verwöhnt werden, stellt sich die Situation für die neue Testsprache anders dar.

Natürlich liefert der Compiler mehr oder weniger hilfreiche Fehlermeldungen, und immerhin wurde ein einfaches Eclipse-Plugin entwickelt, um zumindest Schlüsselwörter hervorzuheben, aber von einer echten Toolunterstützung kann keine Rede sein. Es gibt keine Codevervollständigung, keine automatische Formatierung, und auch die Integration mit den anderen Tools ist minimalistisch.

Erste Abschätzungen deuten auf mehrere Personenjahre an Entwicklungsaufwand hin, um hier auch nur annähernd dahin zu kommen, wo die Entwicklung mit Java oder C schon lange ist. Und gemacht hat das auch noch keiner im Unternehmen.

Ein hoher Aufwand und ein hohes Risiko, welche in keinem Verhältnis zum Nutzen stehen.

Also war die eigene Sprache ein Irrweg? Oder muss man mit dem schlechten Tooling leben?

Mitnichten!

Es handelt sich hier um ein gelöstes Problem. Die Idee, domänenspezifische Sprachen mit Language-Workbenches zu entwickeln, existiert seit Jahrzehnten. Der Begriff wurde vor 14 Jahren geprägt. Doch während es sich damals noch um Experimente handelte, die noch nicht wirklich produktionstaugilch waren, sind diese Tools mittlerweile ausgereift und verkürzen die Entwicklung von Werkzeugen für DSLs um den Faktor 10 und mehr.

Mit wenigen Wochen Aufwand können bereits beeindruckende Ergebnisse erzielt werden; mit noch etwas mehr Mühe kommt man nahe an das Tooling heran, welches man von Java gewöhnt ist.

Insbesondere im Open-Source-Umfeld um Eclipse herum existiert mit Xtext eine Lösung, die exakt diesen Anwendungsfall optimal unterstützt, eine existierende Sprache mit wenig Aufwand um hervorragendes Tooling zu erweitern. Warum Zeit und Geld verschwenden, um das Rad mal wieder neu zu erfinden, wenn man einfach auf die Arbeit von anderen aufbauen kann? Du hast ein ähnliches Problem?

Schreibe uns gerne deine Erfahrungen in die Kommentare oder sprich uns an!

P.S.: Langweilig wird mir das nicht … auch wenn ich meine, das alles schon einmal erlebt zu haben. Hat ja manchmal auch Vorteile.