Rogoit Webdesign Duisburg

Webdevelopmet Blog

Clean Code, PhpStorm Tricks, TYPO3, Codeception, Command Line Interface, Software-Qualität und vieles mehr.
Webdevelopment Blog
 

Test Driven Code Review (TDCR) – pro und contra

Gastbeitrag - Never Code Alone
desk: test driven code review

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.

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?

Franziska Hahn

Franziska arbeitet seit 2008 in der Webentwicklung und ist dabei über eine Agentur und eine Community zur FinTech gelangt. Neben der Backend-Entwicklung beschäftigt sie sich auch mit der Skizzierung von Prozessen. Sie ist leidenschaftliche Speakerin mit dem Fokus, Zuhörer über den Tellerrand blicken zu lassen.

No Comments

Post a Comment

Comment
Name
Email
Website