In der professionellen Softwareentwicklung gibt es eine Methodik namens «Test Driven Development» (TDD). Es gibt sie bereits seit mehr als 20 Jahren, aber seit sie an Hochschulen gelehrt und in der Industrie gelebt wird, nimmt ihre Popularität stets zu. TDD besteht aus drei Phasen:
Rot: Zuerst schreibt der Programmierer einen automatisch ausführbaren Testfall. Dieser sollte noch nicht erfolgreich ausführbar sein (eben rot). Man könnte diesem Schritt auch Spezifikation sagen.
Grün: Den obigen Testfall macht man nun erfüllbar, indem der zu testende Code geschrieben wird. Das Feature oder ein Teil davon wird implementiert und der Testfall ist dann grün. Man könnte diesem Schritt auch Verifikation sagen.
Refactoring: In der dritten Phase schaut man den geschriebenen Programmcode nochmals an und überprüft methodisch, ob man etwas noch besser machen könnte (stabiler, sicherer, schneller). Das nennt sich Refactoring und ist wichtig für die künftige Entwicklungsgeschwindigkeit.
Obige drei Phasen laufen in der Praxis sehr schnell ab. Ein Zyklus dauert nur etwa 30 Sekunden.Obwohl TDD als state-of-the-art angesehen wird, ist die Diskussion darüber noch lange nicht vorbei. An einer Weiterbildung wurde diskutiert, welchen Einfluss TDD auf die Architektur eines Softwareprojektes haben kann. Ich baue darauf auf und erläutere meine Theorie darüber, was passiert, wenn Junior-Entwickler nicht verantwortungsvoll begleitet werden: https://medium.com/@schmijos/test-induced-design-damage-3bc30ed5bc7c
