Einige der Prinzipien:

Pair-Programming: (Zwei Entwickler teilen sich eine Tastatur und Monitor – einer codiert, einer denkt mit) Vorteil: Wissensaustausch technisch und projektbezogen

Build: Integration der einzelnen Komponenten zu einem lauffähigen Gesamtsystem in kurzen Zeitabständen

Test first development: Es werden erst die Unit-Tests geschrieben, bevor die eigentliche Funktionalität programmiert wird. Die Tests werden vom Entwickler ausgeführt, bevor der Code eingecheckt wird.

Enge Einbeziehung des Kunden, d.h. der Kunde gibt das Iterationsziel vor und hat sofort die Möglichkeit Akzeptanztests durchzuführen.

Laufende Refaktorisierung, ständige Architekturverbesserung Akzeptable Arbeitszeit : 40-Stunden-Woche, denn Überstunden mindern die Freude an der Arbeit und somit auch die Qualität des Produkts.

Der Kunde testet die aktuelle Build Version durch den Akzeptanztest. Ein Akzeptanztest ist oft Grundlage für eine Rechnungsstellung. Beim Akzeptanztest betrachtet der Kunde die Applikation und ob das Verhalten den Anforderungen und Wünschen entspricht, nicht aber den Sourcecode. Am Ende gibt es ein Prüfprotokoll, ob die Anforderungen mit dem Pflichtenheft übereinstimmen.

Die Qualitätsicherung von Software lässt sich mittels definierten Unit Tests überprüfen. Die Tests überprüfen das Verhalten von Teilen einer Applikation. Ein Test selber zielt immer nur auf einen kleinen Bereich ab, auf eine Unit. Eine Unit ist eine public Methode einer Klasse, die von der Anwendung genutzt wird. Der Unit Test ruft die Methode auf, mit gültigen und ungültigen Parametern. Das gewünschte Verhalten der Methode wird im Test überprüft.

Zu jedem Projekt wird in der Solution ein gleichnamiges Projekt mit der Endung (.test für die Übersicht) vom Typ dll erstellt. Unit Tests werden normalerweise nicht ausgeliefert. Im Visual Studio Team System kann das Gerüst des Unit Test inzwischen auf Knopfdruck generiert werden. Das Ausführen übernimmt Visual Studio 2008 selber, oder PlugIns fürs Studio oder externe Programme wie Nunit.

Welchen Sinn hat das Ganze: wenn ich eine Methode implementiere, gibt es dazu ja auch Vorstellungen im Kopf, eine Vorgabe oder ein Pflichtenheft, auf jeden Fall ein klares Verhalten und nicht Verhalten (Fehlerfälle, Exceptionhandling). Mit einem Test des Verhaltens kann immer eindeutig festgestellt werden, ob es nach Änderung, Erweiterung im Sourcecode eine Änderung der Methode bewirkt. Also z. B. wenn ein Kollege etwas ändert, und es doch Auswirkungen hat, an die keiner gedacht hat.(Seiteneffekte ausschließen) Es muss nicht einmal eine Änderung im Sourcecode sein, es kann darum gehen, sein Produkt nach Einspielen eines Security Hotfixes , eines SP des Betriebssystems oder auf einem neuen Betriebssystem zu testen.

Die meisten Entwickler werden nun denken, dass ist ja sehr zeitintensiv, da muss ich ja so viele Tests schreiben – „Jein“. Es ist ein Selbstschutz für den Entwickler, damit er bestätigen kann, die Implementierung laut Definition erfolgreich umgesetzt zu haben. Der erstellte Unit Test wird nun so lange wiederkehrend ausgeführt, solange auch der Code dafür existiert, bis zum Ende der Lifetime des Produkts. Der Einmalige Aufwand der Unittest Erstellung zum Zeitpunkt wo die Anforderungen noch klar sind, steht in keinem Verhältnis für den Aufwand der über Jahre hinweg notwendig werden kann, einen Qualitätslevel hinterherzuprogramieren.

Für jede genutzte Methode muss es Unit Tests geben. Ein Test besteht immer nur aus wenigen Zeilen. Den Mock Daten (fixen Daten bzw. Objekte zum Testen), dem Aufruf der Methode die getestet werden soll, und dem Vergleich erwartetes und tatsächliches Resultat). Jeder Entwickler schreibt immer seine Unit Test zu seinem Code. Beim Schreiben des Tests bemerkt man nun, wie die eigene Klasse zu benutzen ist. Oft stellt sich nun heraus, dass dies gar nicht so angenehm ist, etwas fehlt, oder gleiche Parameter mehrmals übergeben werden, ein Parameter fehlt usw. Deswegen gibt es den XP Ansatz, den Unit Test vor der bzw. gleichzeitig mit der Implementierung der Klasse umzusetzen. Dadurch ergibt sich nämlich ein entschiedener Vorteil: Man denkt vorher nach, was man haben möchte, schreibt kein unnötigen Code (noch mehr Tests). Das ist ein Umdenkprozess beim Entwickler, aber so arbeitet man wesentlich effektiver. D.h. ich schreibe zuerst die Unit Test, das spiegelt für mich die API dar, die ich mir vorstelle und auch wie ich das Verhalten der Methoden haben möchte. Pro Methode gibt es jeweils mehrere Tests. Da das Projekt inklusive der Tests kompilierbar ist, habe ich nun erreicht, dass mein Soll / Ist Vergleich im Build messbar wird. Zu Beginn gibt es viele Tests, die fehlerhaft sind (rot), da sie noch kein Ergebnis erhalten, aber immer mehr Tests werden grün und damit funktionsfähig.

Code Wartbarkeit

Die Zeit der Fehlersuche und Behebung hat unmittelbar mit der Codequalität, dem Einhalten der Coding Richtlinien, zu tun. Jedes Teammitglied hat sich daran zu halten, jeder muss den Code des anderen lesen und ausbessern können. Um die Wartbarkeit zu verbessern, wird sogenanntes Refactoring angewandt. Das Betriff Lesbarkeit, Testbarkeit durch unit tests, Modularität und Redundanz. Refactoring wird nur bei funktionierendem Code durchgeführt, bei dem die Funktion erhalten bleibt. Damit sichergestellt wird, dass das Verhalten gleich bleibt, werden Unit Tests verwendet. Dafür gibt integrierte Möglichkeiten im Visual Studio, aber auch Tools, etwa den Resharper der Firma Jetbrains.

Praxis

Beim der Neuerstellung (Projektstart) eines Visual Studio Projects werden die einzelnen Projekte (dll, Forms, Web, …) festgelegt. Parallel dazu werden die Projekte für Unit Tests erstellt. (.test). In den Unit Tests manuell bzw. automatisch erstellt. Durch das Konzept der Software Architektur ist mir bekannt, welche Klassen welche Funktionen wiederspiegeln.

Unter Berücksichtigung des XP Ansatzes, die Unit Test zuerst zu schreiben, werden nun die Unit Test erstellt. Diese sind jetzt beim Ausführen rot, aber das ist beabsichtigt. Damit lässt sich nun von Projektstart an eine Qualitäts-und Fortschrittsmessung protokollieren, die Entwicklung ist von Anfang an transparent. Aussagen von Entwicklern wie „ich bin zu 75% fertig“, die bisher aus dem Bauch heraus getroffen wurden, werden damit überprüft. Ich kann quasi zusehen, wie die geplante Iteration fertig wird. Es kann kein Bereich der Implementierung vergessen werden, Abhängigkeiten der Klassen werden sichtbar, eine Verteilung im Team ist wesentlich einfacher möglich. Am Ende das Tages sieht jeder ein Ergebnis, nämlich das ein oder mehrere Tests grün sind, also messbar auch für den Entwickler, psychologisch wichtig, etwas geleistet zu haben.

Voraussetzung ist immer, dass es ausreichend Unit Tests gibt, die tatsächlich eine sinnvolle Prüfung der Methode vornehmen. Für die Verwaltung der Unit Test Ergebnisse gibt mehrere Möglichkeiten: sammeln der Email HTML Reports, schreiben der Ergebnisse in eine Datenbank, Reporting Server verwenden.

Was mache ich aber bei einem Projekt, wo es noch keine Unit Tests gibt? (Existierendes Projekt)

XP sagt, ein und derselbe Fehler darf kein zweites Mal auftreten. Wie ist das möglich? Durch Unit Tests. Wenn ein Fehler auftritt, ist es immer der erste Schritt diesen zu reproduzieren. Genau das ist der Code für Unit Test. Der nächste Schritt ist, einen Bugfix dafür zu schreiben. Anschließend wird der Unit Test ausgeführt, er wird grün sein. D.h. für diesen Fehler gibt es nun einen Test, den ich im Build ausführen kann. (Wiederauftreten -Regression) Change Requests – Änderungen im Sourcecode notwendig

Die Ausgangssituation ist, es gibt eine Anwendung und einen Unit Test dazu. Ein Entwickler muss eine Änderung im Code eines anderen Entwicklers vornehmen. Der Entwickler überprüft nun zuerst den bestehenden Test, dieser wird funktionieren. Er erkennt nun das Verhalten des Codes. Die Änderung kann vorgenommen werden. Im Anschluss wird der vorige Unit Test durchgeführt, bis dieser wieder grün ist. Zur Sicherheit werden auch alle anderen Unit Tests durchgeführt, ob es hier nicht auswirkende Zusammenhänge gibt. (test-driven software development) Es wird nichts implementiert, was nicht auch getestet wird.

Unit Tests zielen auf Teile der Business Logik, Datenbank Layer ab. Nicht für Web oder Windows Forms GUI geeignet, dafür gibt es Produkte wie Mercury. D.h. die Qualitätssicherung durch Unit Tests wird entscheidend besser, jedoch muss ein User auch die Oberfläche durchklicken und das Ergebnis mit dem Designvorschlägen des Pflichtenhefts überprüfen. Vor allem bei Web Anwendungen kommen noch viele Faktoren hinzu, Bsp. gefühlte und tatsächliche Performance, Verhalten des Browsers etc.