Wir sind nun schon seit einigen Wochen damit beschäftigt, eine ziemlich komplexe Codebasis von knapp 500 Klassen zu überarbeiten. Keiner von uns kannte wirklich alle Details über diesen Teil des Systems, aber wir haben uns davon natürlich nicht abhalten lassen. Nach einiger Umgruppierung/Umstrukturierung/Faktorisierung/*ing war das Ganze in Ordnung und alle Unit-Tests waren wieder grün. Alles, was noch zu tun war, war, die Fitnesse-Tests zu korrigieren. Ich erinnere mich, dass ich dachte, das sollte einfach sein, da wir alle grünen Unit-Tests hatten. Böses Gelächter.
Wir verlassen uns stark auf Fitnesse, weil wir damit Spezifikationen für unseren Code in einer Weise schreiben können, die sowohl ausführbar als auch für andere verständlich ist. Sie können sogar Testfälle fertigstellen, bevor die Codierung abgeschlossen ist, so dass die Tests als Teil der Definition von "done" für eine User Story während eines Sprints funktionieren. Die Tests halfen uns zu verstehen, was der Code tun sollte, und zwar auf einer viel höheren Abstraktionsebene als ein Unit-Test. Dadurch war es einfacher herauszufinden, was eigentlich passieren sollte, und die Fehler zu beheben, die durch unser Refactoring entstanden waren. Da die Fitnesse-Tests etwa 20.000 Behauptungen aufstellen, sind wir ziemlich sicher, dass der Code immer noch das tut, was er vorher tat.
Verfasst von

Jan Vermeir
Developing software and infrastructure in teams, doing whatever it takes to get stable, safe and efficient systems in production.
Unsere Ideen
Weitere Blogs

Testgetriebene Entwicklung (TDD) mit dbt: Erst testen, dann SQL
Testgetriebene Entwicklung mit dbt: Erst testen, dann SQL Wenn Sie mehr als drei Tage als Analytik-Ingenieur verbracht haben, hatten Sie...
Dumky de Wilde

Python Mocking, die heimtückischen Bits
Bei dem Versuch, eine Funktion in meinem Python-Code zu spiegeln, bin ich auf diesen hervorragenden Blog von Durga Swaroop Perla gestoßen. Der Blog...
Jan Vermeir
Contact

