Testing-KnowHow

Wie gut muss die Qualität des Codes beim Testwerkzeug sein? Die Schulbuchantwort ist klar: (Mindestens) Gleich gut wie diejenige des produktiven Codes. Dafür gibt es verschiedene Gründe. Da wäre beispielsweise die Lebensdauer des Codes zu nennen: Der Code, mit dem die Regressionstests ausgeführt werden, lebt ebenso lang, wenn nicht sogar noch länger, wie das System under Test (SUT). Oft überleben sie das SUT sogar und werden als Referenz für das Nachfolgesystem weiter benützt.

Die Notwendigkeit ist also klar gegeben. Trotzdem ist es schon hart genug, die Testautomatisierung synchron zur Entwicklung hochzuziehen und eine ausreichende Abdeckung mit automatisierten Systemtests zu erreichen. Bereits dafür fehlt oft die nötige Zeit oder die Ressourcen. Und deshalb bleibt dann manchmal eben die Codequalität  auf der Strecke.

Die bei uns eingesetzten Werkzeuge Findbugs, PMD und Checksyle kennen da keine Gnade. Die Rulesets sind die gleichen wie beim produktiven Code und entsprechend fliegen uns auch die Violations um die Ohren. Und dann ist da noch das Problem, dass ich beim neuen Code darauf achte, regelkonform zu sein, aber dann sind da noch die Hunderte von Violations, die eben schon vorher drin waren. Und das schlägt dann eben auch noch etwas auf die Motivation.

Ähnliche Probleme stellen wir auch bei unseren Unittests fest. Auch da fällt es schwer, die gleiche Qualität zu erreichen und einzufordern.

Da bleibt wohl nichts anderes übrig, als sich wieder einen Ruck zu geben – und dann los auf die Violations. Heute wird aufgeräumt!