3.4 Code organisieren

3.4.1 Testcode vs. Produktionscode

Testcode hat einen spezifischen Zweck, er soll die Qualität des Produktionscodes sicherstellen, diesen aber nicht außerhalb der eigentlichen Testumgebung beeinflussen. Deshalb sollte Testbarkeit nie der einzige Grund für eine Designentscheidung sein.

Beispielsweise könnte es als sehr einfach erscheinen, private Klassenbestandteile durch eineÄnderung der Sichtbarkeit aufpublicöffentlich sichtbar und somit einfach zugänglich für Tests zu machen. Dies stellt jedoch einen tiefen Eingriff in das gesamte Design dar, bricht es doch die Kapselung der inneren Logik auf, was zu größeren Abhängigkeiten innerhalb des Gesamtsystems der Applikation führen kann.

Um dies zu vermeiden, sollten sich Tests also zunächst wie jeder andere Konsument einer Funktionalität verhalten und möglichst keine Voraussetzungen an den zu testenden Code stellen, dieüber die Schnittstellenbeschreibung hinausgehen. Vielmehr sollten sie auch physisch vom Produktionscode getrennt und in eigenen Projekten verwaltet werden. Auf diese Weise wird von vornherein eine Vermischung mit der eigentlichen Applikation vermieden und es kann nicht versehentlich geschehen, dass Testcode in die tatsächliche Produktionsumgebungübernommen wird, wo er im ungünstigsten Fall selbst zu Fehlern führt und die Wartbarkeit behindert.

3.4.2 Separierung von Tests

Neben der reinen Separierung von Test- und Produktionscode empfiehlt es sich, auch die einzelnen Testarten, wie sie in Kapitel 1.1 beschrieben wurden, voneinander zu trennen. Auf diese Weise kann wesentlich besser auf ihre Besonderheiten in Bezug auf Ausführungsgeschwindigkeit und Ressourcenbedarf eingegangen werden, was darüber hinaus noch durch die Einführung einzelner Projektmappen unterstützt wird.

Dies erlaubt beispielsweise eine Solution, die nur von den Entwicklern verwendet wird und neben dem tatsächlichen Produktionscode auch die Unit Tests enthält. Auf diese Weise können die wichtigsten Tests parallel zur Programmierung ausgeführt werden, ohne lange Wartezeit auf ihr Ergebnis. Eine weitere Projektmappe, die neben Produktionscode und Unit Tests auch Integrations- und Systemtests enthält, wird dann nur von spezifischen Personen editiert und gezielt nach jedem Check-in oder einmal am Tag in dafür vorbereiteten Testumgebungen ausgeführt. Somit kann garantiert werden, dass die Applikation in Gänze und ohne Zeitdruck geprüft wird. Darüber hinaus ist abgesichert, dass alle notwendigen Ressourcen, wie zum Beispiel Datenbanken, auch bereitstehen, wodurch falsche Ergebnisse vermieden werden, die ggf. auf einen fehlerhaften Testaufbau zurückzuführen wären.

Unit Tests organisieren

Unit Tests müssen möglichst schnell auf jedem Entwicklerrechner und hohe ohne aufwändigen Testaufbau ausführbar sein. Da sie vor allem die Funktionalität einzelner Klassen testen, können und sollten sie auch mit genau jenen Klassen verteilt werden, falls diese in andere Programmeübernommen werden. Aus diesem Grund bietet es sich in größeren Applikationen an, zu jedem Projekt, das zu testende Klassen enthält, auch ein eigenes Projekt für die dazugehörigen Unit Tests bereitzustellen. Dieses kann dann einem einfachen Namensmuster folgen:

[Projektname].UnitTests

Im Beispielszenario dieses Buches existiert demnach zum ProjektTwitter.Core, das die eigentliche Geschäftslogik enthält, ein Testprojekt mit dem NamenTwitter.Core.UnitTests. Sollte die Logik der Applikation also weiterverwendet werden, kann sie ohne Weiteres mit den dazugehörigen Testsübertragen werden. Darüber hinaus verringert diese Aufteilung das Risiko eines sehr großen Testprojekts mit vielen Abhängigkeiten, das seinerseits schwer zu deployen und zu warten ist.

Systemtests organisieren

Systemtests, wie zum Beispiel