Scrum und XP im harten Projektalltag
Scrum und XP im harten Projektalltag
Scrum und XP im harten Projektalltag
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
WIE WIR SCRUM MIT <strong>XP</strong> KOMBINIEREN| 85<br />
red<strong>und</strong>anten Code zu beseitigen. Und dann das ganze<br />
Prozedere wieder von vorn..<br />
Einige Überlegungen zur testgetriebenen Entwicklung (TDD) :<br />
• TDD ist schwierig. Egal wie viel sie auch schulen, coachen <strong>und</strong><br />
demonstrieren. Bis ein Programmierer es wirklich versteht hat,<br />
vergeht eine Weile. Oft ist es erst die Programmierung <strong>im</strong> Paar<br />
mit einem TDD-erfahrenen Entwickler, die einen Testgetriebene<br />
Entwicklung wirklich kapieren lässt. Hat man es aber erst einmal<br />
kapiert, ist man dauerhaft infiziert <strong>und</strong> will kaum noch anders<br />
arbeiten<br />
• TDD hat einen durchweg positiven Einfluss auf die<br />
Systemarchitektur.<br />
• Es dauert eine Weile, bis man TDD effektiv bei<br />
Neuentwicklungen einsetzen kann, insbesondere für Blackbox-<br />
Integrationstests. Aber der Aufwand zahlt sich schnell aus.<br />
• Gewährleisten Sie eine mühelose Testentwicklung, indem Sie<br />
z.B. die richtigen Tools bereitstellen, die Kollegen fortbilden <strong>und</strong><br />
Ihre APIs um notwenige Hilfs- oder Basisklassen erweitern.<br />
Folgende Tools für die Testgetriebene Entwicklung kommen bei uns zum<br />
Einsatz:<br />
• jUnit / httpUnit / jWebUnit. Wir überdenken den Einsatz von<br />
TestNG <strong>und</strong> Selenium.<br />
• HSQLDB als eine integrierte, in-memory Datenbank für<br />
Testzwecke<br />
• Jetty als ein integrierter in-memory Web Container für<br />
Testzwecke<br />
• Cobertura zum Messen der Testabdeckung<br />
• das Spring Framework für die Konfiguration der<br />
unterschiedlichen Test Fixtures (mit <strong>und</strong> ohne Mock-Objekte, mit<br />
externer oder in-memory Datenbank, usw.)<br />
TDD bei Neuentwicklungen<br />
Wir setzen TDD bei jeder Neuentwicklung ein, auch wenn das die<br />
Startphase eines Projekts verlängert (z.B. weil wir zusätzliche Tools <strong>und</strong><br />
Vorarbeiten für die Testumgebung brauchen). Verglichen mit den großen<br />
Vorteilen ist dieser Mehraufwand nicht der Rede wert <strong>und</strong> keinesfalls eine<br />
Ausrede, TDD nicht einzusetzen.<br />
TDD bei bestehendem Code<br />
Testgetriebene Entwicklung ist so schon schwierig, sie aber auf einer<br />
Codebasis zu betreiben, die nicht von Anfang an mit TDD gebaut wurde<br />
... ist wirklich sehr schwierig! Warum? Nun, darüber könnte ich mich
Change language