Test Driven Code Review (TDCR) – pro und contra

In diesem Gastbeitrag bringe ich auf den Punkt, für wen sich Test Driven Code Review eignet und für wen nicht. Zudem erläutere ich abschließend, welche Idee hinter TDCR steckt.
Auch wenn diese Prozessform in der Entwicklung vielleicht nicht völlig untypisch ist (bzw. in leicht abgewandelter Form hier und da schon gänzlich etabliert ist), hört man doch praktisch nie „Wir arbeiten mit TDCR“. Deshalb möchte ich diese Abkürzung gerne etablieren und beschreiben. Vielleicht findet der eine oder andere Leser sich wieder oder probiert diese Form der Entwicklung selbst aus.

Für wen eignet sich TDCR (nicht)?

Ich fange hier ganz unkonventionell mit dieser Frage an, damit du nicht bis zum Ende lesen musst, falls du dich nicht wiederfinden kannst.

TDCR ist nichts für dich, wenn …

• du alleine (ohne Development Team) arbeitest.
• euer Team bereits mit Test Driven Development glücklich geworden ist.
• wirklich niemand automatisierte Tests schreiben möchte (man kann ja niemanden zwingen).

TDCR eignet sich (vielleicht) für dein Team, wenn …

• ihr als Team erste Erfahrungen mit automatisierten Testen sammeln wollt.
• die Erfahrungen bzgl. automatisierten Tests im Team schwanken.
• Test Driven Development (TDD) schon erprobt wurde, dies aber nicht das Wahre für eure Use Cases ist.
• ihr schon mit Behaviour- bzw. Domain Driven Development arbeitet und es euch nicht wichtig ist, ob die Tests vor der Business-Logik implementiert werden.
• die meisten Pull-Request-Kommentare sich auf Styleguide oder Tippfehler beziehen.
• es für euch wichtig ist, Wissensinseln zu vermeiden oder zu verringern.

Was ist TDCR?

Jede Wissensinsel hat ein Dock.

Die Idee von Test Driven Code Review ist simpel: Ein oder mehrere Entwickler schreiben Code, und ein oder mehrere andere Entwickler schreiben dazu Tests.

Damit wird der klassische Ticketprozess „Open > In Progress > In Code Review > In Testing > Deployment“ etwas agiler: Denn die Code Review wird schon von dem Entwickler durchgeführt, der die Tests schreibt. Er liest sich in den Code und dessen Zusammenhänge ein, entwirft eventuell Testszenarien, prüft die Testbarkeit und passt ggf. die Codestruktur so an, dass sich alle Bereiche gut testen lassen.

Denn lässt sich Code nicht testen, ist er vermutlich nicht gut genug strukturiert.

Meine Erfahrung zeigt, dass diese Methode dazu führt, sich mehr um das große Ganze zu kümmern, als sich mit Styleguide-Diskussionen aufzuhalten. Natürlich ist auch die Einhaltung eines Codestyle-Standards wichtig – dies lässt sich aber viel leichter automatisiert prüfen als die Einhaltung von Clean-Code-Regeln wie KISS, YAGNI, SOLID und wie sie alle heißen.

Eine weitere Möglichkeit besteht darin, den Code Review Step beizubehalten und dort nur noch zu prüfen, ob die Tests ausreichend sind, die Dokumentation verständlich ist und besagter Codestyle eingehalten wurde.

Welche Erfahrungen hast du bereits mit Test Driven Code Review gemacht?