Innerhalb der agilen Methoden hat sich eine testgetriebene Entwicklung als Muss durchgesetzt, da nur damit die Qualität der Software – höchstes Ziel – sichergestellt werden kann.

Junit Tests sicher dabei die einzelnen Module intern ab (Whitebox).

Auf einer höheren Ebene setzen Acceptance Tests an. Hier kann der Test auch dazu benutzt werden das gewünschte Verhalten des System mit dem „Kunden“ festzulegen.

Auf einen Scrum Vortrag bei Andrea Objekts in Karlsruhe:
http://www.andrena.de/

habe ich fitnesse – basierend auf Fit vom Wiki Erfinder Ward Cunnigham – kennen und beim Einbau in die eigene Tool chain (mit Fitness/Slim) lieben gelernt:
http://www.fitnesse.org

Besonders agile Acceptance Tests – in einer Art Living Dokumentation – erreicht man mit:
http://www.concordion.org

Im Buch Building and Testing with Gradle wird ansatzweise beschrieben, wie gut die Groovy Frameworks Spock und Geb/easyB für Integrationstest geeignet sind:

http://code.google.com/p/spock/

http://www.gebish.org/
http://www.easyb.org/

Living Documentation

Im Trend liegt es die Anforderungen als Akzeptanztests geeignet für ein gemeinsames Verständnis zu erfassen und damit auch automatisch prüfbar zu machen. Insbesondere Gojko Adzik hat hierfür eine Grundlage mit: http://www.amazon.de/Specification-Example-Successful-Deliver-Software/dp/1617290084 gelegt.

Damit soll nun nach mehreren Anläufen endlich der „Schulterschluss“ von Fachbereich und Entwicklung – ein gemeinsames Verständnis geschaffen werden.

Test First

Am besten wirkt die test getriebene Entwicklung, wenn man einen TestFirst Ansatz fährt. In der Praxis werden die Tests jedoch oft noch nachträglich „reingefrickelt“