-
Posts: 1524
Nickname: nitronic
Registered: Jul, 2006
|
Norbert Eder works as a software architect.
|
|
|
|
Mit Unit Tests zur einfacheren und intuitiveren Verwendung
|
Posted: Sep 15, 2008 3:23 AM
|
|
Unit Tests sind ein Thema bei dem es Entwickler wie Ärzte halten: Gehe zu vier Ärzten und erhalte fünf Meinungen. Bei Unit Tests läuft es auf dieselbe Art. Also wie jetzt wirklich?
Mit den in Visual Studio integrierten Test-Möglichkeiten sollte man meinen, dass der Entwickler nun wirklich keine Ausrede mehr parat hat, Unit Tests nicht zu schreiben. Weit gefehlt. In vielen Projekten werden derartige Tests noch immer vernachlässigt bzw. im schlimmsten Fall nicht angedacht. Einen der Hintergründe - das Thema Aufwand - hatte ich schon einmal versucht, aus dem Weg zu räumen. Oft erscheinen Tests jedoch auch zu kompliziert, oder es wird diese großartige Unterstützung schlicht einfach nicht bedacht.
Für Unit Tests spricht aber nicht nur, dass damit die Fehlerfreiheit von Teilen der Software verbessert und laufend überprüft werden kann. Der Entwickler kann damit sich selbst, dem Team und neuen, zukünftigen Mitgliedern die Arbeit ebenfalls wesentlich erleichtern. Wie denn das?
Der Eckpfeiler daran ist, sich vor der tatsächlichen Implementierung eines Arbeitspaketes Gedanken zu machen, wie die resultierenden Klassen getestet werden können. Idealerweise werden die Tests vor der Entwicklung dieser Teile geschrieben, muss aber nicht zwingend passieren. Da sich der Entwickler nun im Vorfeld schon Gedanken über die Verwendung macht, wird daran gefeilt, bis eine leichte, intuitive Verwendung möglich ist. Schließlich möchte niemand 10 Zeilen Sourcecode schreiben, nur um eine einfache Berechnung auszuführen. Das Ergebnis ist also ein klares, einfach verständliches Design, welches sowohl die gestellte Aufgabe erfüllt und zudem nach der Implementierung voll funktionsfähig ist. Fehlen Gedanken zur Anwendung, kann letzterer Punkt nicht immer sichergestellt werden. Änderungen am Design sind daher im Nachhinein nötig und führen mitunter sehr schnell zu einer Verwässerung des ursprünglichen Designs.
Der Nachteil daran ist einfach erklärt: Neben der Notwendigkeit, sämtliche Dokumentationen zu ändern (Design Dokument etc.) hat sich durch die spätere Änderung das Design eventuell so stark verändert (meist durch Work-Arounds), dass die Code-Teile nicht mehr intuitiv zu verwenden sind. Team-Kollegen, neue Mitstreiter oder eventuelle Kunden, die programmiertechnisch damit in Berührung kommen, müssen sich lange durch die Dokumentation quälen anstatt durch einen ersten schnellen Tests die Funktionsweise zu verstehen. Eine einfache Sache kann also schnell zu einer Katastrophe ausarten.
Der weitere Ablauf liegt ebenso auf der Hand: Irgendwann wird ein anderer findiger Entwickler diesen Sourcecode zur Überarbeitung markieren. Es entsteht ein Arbeitspaket mit der Prioritätsstufe niedrig - wenn sich einmal Zeit findet. Bis dieser Tag angebrochen ist (in der Regel nie) werden an diesen Stellen vermutlich zahlreiche Funktionserweiterungen implementiert. Ein einfaches Austauschen ist somit auch nicht mehr möglich. Treten zu einem späteren Zeitpunkt gerade hier vermehrt Fehler auf, wird ein alter Spruch missbraucht: Das ist im Laufe der Zeit so gewachsen..
Als Tipp kann ich daher nur jedem Entwickler mitgeben: Bereits im Vorfeld sind Gedanken über die spätere Verwendung von Code-Teilen notwendig. Sinnvoll kann es natürlich sein, nach einem ersten Grob-Design mit einem Testfall zu beginnen. Anhand dessen kann abgeleitet werden, ob die angedachte Verwendungsweise tatsächlich gut ist, oder ob Nacharbeit notwendig ist. Nach zwei bis drei Iterationen über diese Punkte hat sich ein Verständnis für dieses Arbeitspaket entwickelt und auch die Verwendung sollte weitaus klarer und intuitiver sein, als dies vermutlich beim ersten Ansatz der Fall war.
Read: Mit Unit Tests zur einfacheren und intuitiveren Verwendung
|
|
Previous Topic
