Peter Bucher - Mein Experiment, meine Spielereien, meine Welt...   ·   Stefan Falz   ·   Jürgen Gutsch   ·   Golo Roden   ·   ASP.NET Zone   ·   Microsoft ASP.NET
Willkommen bei ASP.NET Zone. Anmelden | Registrieren | Hilfe

Wieviel Sinn machen Unittests?

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Roden? Ja, Bucher! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen.
Außerdem nimmt diesen Monat auch Christian Wenz wieder an unserem Streitgespräch teil.

Bisher sind in dieser Reihe folgende Kommentare erschienen:

Heute, am 1. November 2009, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:

Wieviel Sinn machen Unittests?

So wohl Golo wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Golos Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:

Schon in einem früheren Streitgespräch “Die Forderung nach Softwarequalität” habe ich Unittests erwähnt.

Ich würde als direkte Antwort natürlich gleich sagen: Sehr viel Sinn!
Jedoch muss die Frage irgendwie auseinandergenommen werden, denn generell lässt sie sich nicht beantworten.

Wo macht Unittesting Sinn?

Grundsätzlich macht es überall Sinn, wo das Verfahren leicht anzuwenden ist, ohne irgendwelche Handstände zu machen.

Schwierige Testumgebungen

Gerade in der Webentwicklung bzw. überall wo eine Oberfläche vorhanden ist, wird es schwieriger Abläufe zu testen.

Handelsübliche ASP.NET (WebForms) Anwendungen die schon entwickelt sind, jedoch nachträglich getestet werden müssen, eigenen sich überhaupt nicht dazu, nachträglich mit Unittesting zu versorgt zu werden.
Das liegt daran dass die Zuständigkeiten (Concerns) physikalisch und auch logisch nicht strikt getrennt sind, sondern schlussendlich bei den meisten Anwendungen irgendwo in den Page-Eventhandlern liegt.

Zum “nachträglich” kommen wir dann später noch mal zurück.

Wenn eine ASP.NET Anwendung von Grund auf neu entwickelt wird, kann das MVP (Model View Presenter)-Pattern eingesetzt werden, damit Unittests überhaupt eingesetzt werden können.
Wiederum gibt es ASP.NET MVC, das – wie der Name schon sagt – auf das MVC (Model View Controller)-Pattern setzt, was die Testbarkeit um einiges vereinfacht.
Natürlich gibt es auch dort noch Hürden und auch eine ASP.NET MVC Anwendung kann so geschrieben werden, das sie kaum noch testbar ist.

Für solche schwer testbare Anwendungen sind Oberflächentests der bessere bzw. möglichere Weg und stellen auch einen zusätzlichen Weg dar, für Anwendungen die schon mit Unittests abgedeckt sind.

Optimale Testumgebungen

Am besten eigenen sich kleine Greenfield (Start von der grünen Wiese aus)-Projekte, die – wenn möglich – Bibliotheken sind, die dann später in die Oberfläche integriert werden, bzw. ihre Aufgabe aufgrund einer Aktion der Oberfläche erfüllen.

Ein super Beispiel dafür ist die Entwicklung eines Dependency Injection Containers. Da kann man sogar hergehen und komplett testgetrieben arbeiten, also zuerst den Test und dann der Produktivcode, weil keine äusseren Abhängigkeit oder Oberflächen mit von der Partie sind.
Schlussendlich kann dann so sichergestellt werden, dass der Code das tut, was er sollte, zumindest in den getesteten Szenarien.

Lizenznummern generieren, parsen, zählen, prüfen, auch das ist ein super Beispiel wo Unittesting sehr gut angewendet werden kann, wenn es richtig aufgezogen wird.
Ich würde sogar behaupten es wäre fast unmöglich ohne irgendwelche Tests (Und hier eigenen sich Unittests am besten), so eine Bibliothek aufzubauen und sicherzustellen, damit sie korrekt funktioniert.

Denn erstens kann so sichergestellt werden, dass sich das implementierte Verhalten auch so verhält, wie es der Test vorschreibt und zweitens können Seiteneffekte entdeckt, behoben und schlussendlich ausgeschlossen werden. Denn nach jedem zusätzlich geschriebenen Test, sollten alle Tests noch einmal durchlaufen, so können dann Seiteneffekte erkannt und behoben werden.

Wieviel Testabdeckung ist sinnvoll?

Vielerorts wird geschrieben und gesagt das 100% Testabdeckung das Ziel sein sollte. Ich sage, das es gut ist, seine Ziele hochzustecken. Jedoch sind eben die letzten paar Prozent fast nicht testbar, oder es macht keinen Sinn sie zu testen, entweder weil es viel zu aufwändig ist, oder der Code schon durch Integrationstests abgedeckt ist.

Nachträgliches Unittesting?

Eine Anwendung nachträglich mit Unittests abzudecken macht m.E. nicht sehr viel Sinn.
Es gibt zuviel Aufwand und die Anwendung bzw. dessen Abläufe und verstrickter Code soll bestimmen, wie / wo und was getestet werden soll / muss.
Ich habe das Gefühl, dass sowas sehr schwierig ist, im nachhinein reinzupflanzen, nicht nur wegen dem Aufwand, sondern auch weil man nicht wirklich weiss, was getestet werden soll und wann alles abgedeckt ist.

Anders sieht es bei einem Redesign einer Anwendung aus, dort kann man eher Unittests einbauen, ganz sicher beim neuen Code und dann ggf. noch die Integration mit dem bestehenden Code testen, der dann meistens dabei noch angepasst wird.

Hardcore-TDD?

“Hardcore-TDD”, also zuerst die Tests und erst danach den Produktivcode, oder eher locker mal den Code schreiben und am Schluss die Tests hinzufügen?

Ja, ich gebe es zu, das ist eine Streitfrage. Ehrlich gesagt verstehe ich aber nicht wieso :-).
Irgendwie habe ich das Gefühl das es Extreme gibt, um den Menschen überhaupt klar zu machen, das es so / oder dies und das besser ist, als das bisherige.
Mit dieser Vorgehensweise kann man die Leute zum Aufwachen bringen, sich das überhaupt mal anzusehen – auch bei Clean Code Developer / Clean Code schön zu sehen.

Wenn man vor den Kopf gestossen wird, ist das schon mal der erste Schritt. Der zweite Schritt ist dann, sich mit dem Extremen zu befassen und irgendwo seinen Stil einzuordnen. Ich finde es macht – abgesehen um Leute vor den Kopf zu stossen – überhaupt keinen Sinn, etwas ins Extreme zu treiben.

Immer zuerst den Test schreiben und erst dann den Produktivcode mag bei kleineren Projekten, oder eben solchen die sehr modular und für Tests optimiert aufgebaut sind, funktionieren.

Ich habe das selber auch schon probiert und es ist schon eine coole Erfahrung:

  1. Test schreiben
  2. Benötigte Klassen erstellen
  3. Kompilieren => kompiliert
  4. Test laufen lassen => schlägt fehl => rot
  5. Klassen ausimplementieren, nur das nötigste
  6. Test laufen lassen => läuft => grün

Es gäbe theoretisch noch einen Zwischenschritt, bei dem kompiliert wird, obwohl die Klassen noch nicht vorhanden sind, aber damit kann ich mich irgendwie nicht anfreunden.
Auf jeden Fall macht man sich damit Gedanken, wie man sein API benutzen möchte und modeliert dann die Klassen auch so aus,
zusätzlich wird im besten Fall nur das implementiert was die Tests erwarten, also bis sie grün sind.

So kann mit Leichtigkeit die Einhaltung von YAGNI beim Entwickeln eingehalten werden.

Meiner Erfahrung ist aber leider die, dass vielerorts eben schon Projekte bestehen, die nicht darauf optimiert sind, mit Unittests abgedeckt zu werden.
Sei das jetzt nachträglich oder für neue Features die dazukommen. Dort ist es echt schwierig und da können meistens nur sehr loose angedockte Zusatzbibliotheken getestet werden, also ein Greenfield-Projekt das dann in die bestehende Umgebung eingebunden wird.

Überall wo es möglich ist, nach TDD zu entwickeln, mache ich das jetzt auch – mehr oder weniger, aber nicht komplett im Extremen.

Veröffentlicht Sonntag, 1. November 2009 09:37 von Peter Bucher
Abgelegt unter: , ,

Kommentare

# Wieviel Sinn machen Unit-Tests?

Am 13. Oktober 2008 haben Peter Bucher und Golo Roden unter dem Titel "Noch Fragen, Bucher? Ja, Roden!" angek�ndigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gew�hlten Thema verfassen zu wollen. Heute, am 1. Novembe

Dienstag, 3. November 2009 15:41 by Hauser & Wenz :: Blog

# Reflection – Fluch oder Segen?

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Roden? Ja, Bucher! angekündigt,

Dienstag, 1. Dezember 2009 21:03 by Peter Bucher

# this oder kein this

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Roden? Ja, Bucher! angekündigt,

Dienstag, 16. Februar 2010 21:30 by Peter Bucher

# Felder vs Eigenschaften

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Roden? Ja, Bucher! angekündigt,

Sonntag, 14. März 2010 16:53 by Peter Bucher

# Abstraktion

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Roden? Ja, Bucher! angekündigt,

Freitag, 9. April 2010 13:22 by Peter Bucher
Anonyme Kommentare sind nicht zugelassen