Gerade gestern hat mich ein Artikel unseres alten Scrum-Trainers Markus Gärtner erneut auf die Cyclomatic Complexity-Metrik aufmerksam gemacht. Diese ist besonders praktisch weil sie zu einer Methode direkt sagt wie viele Unit Tests man dafür haben sollte.
Auch in aktuellen Sprints haben wir viele Fehler erst wieder sehr spät beim manuellen Testen bemerkt, sodass wir Schwierigkeiten hatten die angedachten Szenarios bis zum Termin überhaupt einmal durchzuspielen. Die meisten der dazugehörigen Bugs waren schwer zu finden da sie sich gut in teils sehr langen Methoden mit vielen if-else-Verschachtelungen versteckten (d.h. hohe Cyclomatic Complexity). Die entsprechenden Code-Pfade waren vom Entwickler wohl kaum - wenn überhaupt - durchlaufen worden.
Grund genug für mich den Dachboden meiner grauen Zellen zu durchforsten.
Die schönen Ergebnisse aus dem vorangegangen Post kann man mit VS2012 auch erhalten. In der Professional Version gibt es schon Möglichkeiten zur Code Analyse (ähnlich FxCop und StyleCop) deren Ergebnisse einen schon auf viele Defizite aufmerksam machen. Code Metriken soll die Ultimate Version unterstützen.
Aber es geht auch anders. Dazu verwendet man den Code Metrics Viewer 2 CTP welcher
die Roslyn components CTP benötigt welche widerum das VS2012 SDK benötigen.
Ich glaube es wäre sinnvoll Code-Metriken in den Build-Prozess einzubauen. Dafür gibt es beispielsweise ein Jenkins-Plugin. Dieses benötigt aber z.B. FxCop 10 auf dem Buildserver. Hm, mal sehen...
Welche Möglichkeiten gibt es eigentlich in Java? Ich meine gehört zu haben dass insbesondere die Testabdeckung bzw. Code Coverage in Java sehr einfach in den Buildprozess zu integrieren sei.
No comments:
Post a Comment