Vogelperspektive in NUnit

Mit NUnit bin ich als Entwickler quasi “groß geworden”, habe die Tücken von Unit Tests damit schmerzlich erfahren und viele Lektionen damit lernen müssen, insoweit habe prinzipiell eine positive Einstellung zu diesem Werkzeug.

Seit ca. einem Jahr habe ich überwiegend die MS Tests aus Visual Studio verwendet. Zunächst mit wenig Begeisterung, weil ich von anderen Entwicklern viel negatives beispielsweise über die Performance gehört habe.

Die Assertion-API ist zwar etwas rudimentär und nicht so fein gestaltet wie in NUnit, aber ich muss Microsoft ausdrücklich loben. Man kann mit MS Tests sehr gut arbeiten. Durch die Visual Studio Integration, die es übrigens mittlerweile auch in den Express Editions gibt, werden Unit Tests viel nahtloser.

Eine Kleinigkeit in Visual Studio hat jedoch eine enorme Auswirkung und das ist die Darstellung der Testergebnisse.

Zum Beispiel sieht die so aus:

Man kann die Ergebnisse auch anders gruppieren, z.B. so:

In NUnit werden die Testergebnisse stattdessen so dargestellt:

Offensichtlich ist dies ein Baum.

Dieser triviale Baum, der Microsoft vielleicht 2 Personentage mehr an Entwicklung gekostet hätte, macht einen entscheidenden Unterschied, wie ich als Entwickler mit den Unit Tests umgehe.

Als ich mit NUnit gearbeitet habe, habe mir oft das Ergebnis der Test Suite angesehen und dann gedacht, toll: “dies” und “dies” und “dies” funktioniert jetzt alles. Man bekommt auch ein gutes Gefühl, ob eine Unit Test Suite im Verhältnis der restlichen Anwendung eher klein oder umfassend ist.

Mein Umgang mit den MS Test Ergebnissen ist anders. Ich schaue lediglich “all green? OK, weiter mit der Aufgabe”.

Man könnte jetzt dagegen argumentieren, dass man “dies” und “dies” und “dies” ja alles im Quellcode der Tests sieht, aber obwohl ich mir mittlerweile einbilde, dass ich halbwegs lesbare Unit Tests schreibe, ist dies nicht einmal im Ansatz miteinander zu vergleichen.

Beispiel für einen Test Code:

Mal ganz abgesehen von den vielen kognitiven Staubpartikeln wie “public”, “TestMethod” und anderen syntaktischen und API-technischen Erfordernissen, kann ich mir nur eine Datei gleichzeitig ansehen. Auch die Klassenansicht in Visual Studio ist nicht gerade geeignet, um einen Überblick über die Test Cases zu erlangen.

Der Code ist eine absolute Froschperspektive. Die ist natürlich nötig, um die Tests zu erstellen. Aber wir kämpfen schon an anderen Stellen mit so vielen Details und vergessen dann manchmal in den großen Zusammenhängen zu denken. Der NUnit Baum bietet dies und erlaubt in gewissem Maße eine Vogelperspektive.

Beeindruckend welche Auswirkungen “kleine” UI-Entscheidungen haben können. Obwohl MS Tests ansonsten durch die nahtlose VS Integration um Längen besser sind, machen sie das durch die fehlende Baumansicht und die fehlende Vogelperspektive zum Großteil wieder kaputt.