Mein Weg zur testgetriebenen Entwicklung
posted on
Testgetriebene Entwicklung (TDD) funktioniert – überall. Sie scheitert nicht am Kunden, den nicht Qualität sondern Tempo interessiert. Sie steht nicht im Widerspruch zum jungen Projekt mit wenig Budget, das schnell Kunden gewinnen muss um zu überleben. Sie hindert nicht daran schnell Features umsetzen zu können. Ja, sie macht mir auch nicht (mehr) langsamer.
Es ist keine neun Monate her, dass ich das nicht glauben konnte. Mehrere Anläufe hatte ich unternommen neben Code auch Tests zu schreiben. Länger als zwei Monate ging das nie gut:
- Ich fühlte mich produktiver, wenn ich „richtigen“ Code statt Tests schrieb.
- Ich arbeitete in einem Team, das kein Interesse daran hatte Tests einzuführen.
- Es war nicht wichtig fehlerfrei zu arbeiten, die schnelle Umsetzung von neuen Features war was zählte.
- Auch ohne Tests konnte ich relativ fehlerfrei entwickeln.
- Manchmal versuchten wir den Kunden zu überzeugen mit Tests zu entwickeln, aber dieser hatte kein Interesse daran.
- Die Software an der ich gearbeitet habe war nicht besonders gut geeignet testgetrieben entwickelt zu werden. Die Tests funktionierten solange gut wie sie mit den knappen Beispiele aus Büchern gemacht wurden, aber unsere reale Software war zu komplex dafür.
