Eben in dem Blog von Keyvan Nayyeri gelesen:
Unit Testing is Not Always Good
You may be interested to know that how much of unit testing is done for Waegis. Actually I started the development with heavy unit tests for almost everything. Waegis has a core platform that I tried to develop with the best quality and accuracy so I unit tested it carefully. After 1-1.5 months of development I abruptly believed that this project is going to take much longer than my initial estimation. Normally taking longer wasn’t bad but for a self-managed project this could cause to failures so I had to make a new decision.
My decision was to limit my unit tests to some critical parts of code. Based on experience and background these parts are easy to recognize so I chose this approach and this helped me to speed up my development and bring it to the web finally!
Unit testing is great and I’m a big fan of it but this time I had to reduce and limit it in order to get the point. All the proven methodologies, software development processes and practices are there to teach you how to choose the best way so don’t restrict yourself with them!
more...
Ich lese den Blog von Keyvan schon eine Weile. Er ist nicht nur Autor von einigen Büchern im .NET Developmentbereich, sondern auch ein Tool-Developer für verschieden Software. Ich selber nutze seine GraffitiCMS Extras auf diesem Blog.
Keyvan schreibt in seinem Post über seine Erfahrung im konsequenten Einsatz mit Unit-Testing. Er spricht mir aus der Seele. Es es wichtig es zu tun, aber es ist noch wichtiger es zu unterlassen, wenn es sinnvoll und vertretbar ist. Wie beim Designen von Datenbanken, kommt es nicht auf die tausendste Table an, um die vierte Normalvorm zu erreichen. Es ist wichtiger das Ziel vor Augen zu haben und dieses mit vertretbaren Mitteln zu erreichen.
Ich habe zu ".NET 1.1 Zeiten" mit nUnit und Plugins für Visual Studio begonnen. Beim Wechsel auf die Visual Studio Version 2005 war dann schon Unit-Testing direkt mit an Board. Seit der Version 2008 können auch Nutzer, der nicht "Team Editionen" auf die eingebauten Funktionen zurückgreifen. Es wurde also erkannt, das es ein wichtiges Feature ist, dass nicht zwingend an der Größe und Professionalität der Entwicklung gebunden ist.
Wofür nutzt man also Unit-Testing? Meine Antwort gleicht der von Keyvan. Die Core Elemente sollten im permanenten Testing stehen. Am "Core" sollte ab einem gewissen Zeitpunkt so oder so keine gravierenden Änderungen vorgenommen werden. Somit hat man je nach Projektgröße eine überschaubare Anzahl an Test-Items. Für diese Fälle rentiert es sich auch die entsprechenden Aufwände zu betreiben, die Umgebung auf Unittesting vorzubereiten. Die Ausgangssituation solle idealerweise immer dieselbe sein, aber gerade im Fall von Datenbank getriebenen System nicht gerade trivial zu erreichen. Ein weiteres Szenario in dem sich Unit-Testing anbietet, ist das frühe Stadium eine Applikation. Wann wird zum Beispiel das erste Mal der Datenlayer beansprucht? Wie testet man die Login-Methode von die ASP.NET Front noch nicht steht? In solchen Fällen behilft sich der Entwickler in der Regel mit einer WinForm Applikation: WindowsFormsApplication1. Nach drei Tagen hat der Knopf "Button 1" die sechste Funktion und ist von vier weiteren Knöpfen mit ähnlichem Schicksal umgeben. Hoffentlich wird dann nicht im Team entwickelt. Chaos ist vorprogrammiert. An dieser Stelle einfach Unit-Testing angewandt and und dann einfach in Ruhe lassen. Das ist kein Code der gewartet werden muss. Bei Konflikten im Refactoring lieber auf eine Migration verzichten.
Intensives Unit-Testing wird gerade in "schnellen" (kurzen wie auch schnell wechselnde Anforderungen) Projekten eher zum Hindernis. Bei einem kleinen Projekt auf einen Change zu reagieren, kann nicht (darf nicht) bedeuten tausend Zeilen Code fürs Testing anpassen zu müssen. Bei einer vernünftigen Anzahl an Szenarien pro Test sind schnell mehr Zeilen Code im Unit-Test als in der getesteten Klasse gezählt. Die Einfachheit einen Test für eine Klasse mit den mitgelieferten Tools zu erzeugen, ist als trügerisch.
Für was nutzt Unit-Testing? Und wie intensiv?
Ciao Marco
Ich habe meine ersten Erfahrungen während der Beta Phase gemacht. Es ist ein tolles Produkt, allerdings ändert sich erstmal für SharePoint in den meisten Installationen wenig (es sei denn die Performance ist bei gleicher Hardware wirklich besser). Interssant wird meiner Meinung nach, die Integration der Reporting Services mit den neuen Charts. Hat schon jemand gewechselt und kann für SharePoint da ne Aussage treffen? 
