2.3.5 Test First Ansatz

Es haben schon einige Firmen Erfahrung mit dem Test First Ansatz gemacht. Als Beispiel möchte ich aus dem Buch Test-Driven Development (TDD) von Kent Beck zitieren.

Can you test drive enormous systems?

Does TDD scale to extremely large systems? What new tests would you have to write? What you kinds of refactorings would you need?

The largest, totally test-driven system I've been involved with is at LifeWare (www.lifeware.ch). After 4 years and 40 person/years, the system contains approximately 250.000 lines of functional code and 250.000 lines of test code in Smalltalk. There are 4.000 tests, executing in under 20 minutes. The full suite is run several times each day. The amount of functionality in the system seems to have no bearing on the effectiveness of TDD. By eliminating duplication, you tend to create more smaller objects, and those objects can be tested in isolation independent of the size of the application.

Firmen in Deutschland, von denen ich weiss daß sie den Test-First Ansatz in ihren Projekten einsetzen (Diese Liste ist sicher sehr unvollständig):

2.3.6 Test First Ansatz und einfacher Design

• Da wir zuerst die Tests schreiben, zwingen wir uns zunächst über die Schnittstellen des zu erstellenden Codes und erst später über die Implementation nachzudenken. Bzgl. Wartbarkeit ist die Qualität der Schnittstellen entscheidenter, als die eigentliche Implementation. Eine Änderung an einer Schnittstelle bedeudet, dass alle Objekte die diese Schnittstelle benutzen geändert werden muessen. Sind Schnittstellen stabil, bleiben Änderungen in der Implementation lokal.
• Unittests fördern das objektorientierte Denken. Eine Klasse wird als eigenständiges Programmteil gesehen.
• Da der Schwerpunkt auf Testbarkeit, und nicht alleinig auf Korrektheit steht, entstehen viele kleine Klassen, die weitgehend unabhängig voneinander sind, als grosse komplexe Klassen. Für komplexe Klassen ist es nämlich sehr viel schwieriger Unittests zu schreiben.
• Durch andauerndes Refactoring wird fachlich motivierter Code und rein technischer Code getrennt. Der rein technische Code (z.B. Mappen von Objekten in Datenbanken) kann auch in anderen Projekten wiederverwendet werden.

2.3.7 Literatur