MS Test: In und Out – Warum einfach wenn es auch kompliziert geht?

Im Gegensatz zu beispielsweise NUnit, werden Tests bei MS Test nicht einfach im Bin-Verzeichnis des entsprechenden Projekts ausgeführt. Microsoft sieht, oder sah wenn man so will,  die Infrastruktur für Tests im Visual Studio (bis 2010) nicht nur auf Unit Tests, sondern die gesamte Testpyramide bezogen. Dies bezieht also System- und Integrationstests mit ein, welche andere Anforderungen an die Umgebung haben in der sie laufen.

Während es also beim Unit Test vorallem auf die schnelle und einfache Ausführung ankommt, ist in höheren Ebenen mehr auf eine detailierte und nachvollziebare Dokumentation der Ergebnisse zu achten. Letztendlich sollen diese ja von unterschiedlichen Personen einsehbar und je nach Art des Projekts noch nach Wochen bewertet werden können. Leider behindert der Umstand dieser Bandbreite an Einsatzmöglichkeiten den geneigten Entwickler gelegentlich wenn er tatsächlich „nur“ Unit Tests schreiben will.

Ganz besonders merkt man dies meiner Meinung nach daran, dass sich Visual Studio einfach nicht dazu bewegen lässt seine Tests in ein bestimmtes Verzeichnis zu kopieren, bevor es sie ausführt. Genauer werden für jeden Testdurchlauf neue Verzeichnisse in einm Folder „TestResults“ unter dem Solution Verzeichnis angelegt. Die eigentlichen Dateien für den Test kommen dann in einen neuen Ordner der die Namensstruktur [Windows Nutzername]_[Rechnername] [Zeitstempel] hat und selbst wiederrum zwei Verzeichnisse In und Out enthält.

Das Out Verzeichnis speichert dabei alle für den Test notwendigen Daten die direkt deployt werden. Würde man bspw. NUnit nutzen wäre der Out Folder also am ehesten mit dem Bin Verzeichnis zu vergleichen in dem der Test simplerweise ausgeführt wird. Der Bereich unter In hingegen dient vorallem der Ablage weiterführender System Informationen, wobei diese ggf. erst eingeschaltet werden müssen. Dazu zählt bswp. ein XML mit Beschreibungen des verwendeten Betriebssystems und der Harware, was bei groß angelegten Kompatibilitätstests bzw. Labmanagement sicher sehr hilfreich ist. Es gehören aber auch Dinge wie Code Coverage und externe Abhängigkeiten zu bswp. Datenbanken dazu.

Ich will mich jetzt nicht darüber äußern wie gut oder schlecht diese Funktionen tatsächlich sind. Mir geht es eher darum ein Bewusstsein dafür zu schaffen warum es sie überhaupt gibt, denn im Entwickleralltag können sie nerven da man sie einfach nicht abschalten kann.  Zwar ist es möglich über Tools -> Options -> Test Tools -> Test Execution die Anzahl der Verzeichnisse zu begrenzen die erstellt werden, man kann aber deren Erstellung als solches nicht gänzlich verhindern.

So werden im Standardfall max. 24 Verzeichnisse erstellt, durch die man sich die letzten 24 Testläufe noch einmal zu Gemüte führen kann. Beim TDD will ich das aber nicht und muss den Zeitverlust in Kauf nehmen, der entsteht weil alle meine Dateien zunächst von einer Ecke der Platte in die andere kopiert werden.

Zumal, die Begrenzung auf ein Verzeichnis hat einen Haken. Auch wenn die alten Testergebnisse auf 1 begrenzt sind werden die Verzeichnisse nur wirklich dann automatisch gelöscht wenn sie keine schreib geschützten Dateien enthalten. Da es sich beim „Deployment“ aber nur um ein XCopy handelt, ist der Umstand nicht immer gegeben und gelegentlich rutscht doch mal ein File rein, dass den entsprechenden Haken gesetzt hat. Handarbeit ist dann also immer mal wieder notwendig…