Ich programmiere seit 30 Jahren und bin davon die meiste Zeit sehr gut ohne Testing zurechtgekommen. Ich bin den EDV-Dinosauriern nicht böse, wenn sie dieses Kapitel überspringen. Sie können Rails-Applikationen auch ohne Tests erstellen und werden deshalb kein schlechtes Karma bekommen (hoffentlich, sicher kann man bei der Karma-Sache ja nie sein).

Aber sollten Sie sich auf Test-Driven-Development (TDD) einlassen, so kann ich Ihnen versprechen, dass es eine Erleuchtung ist. Die Grundidee von TDD ist, dass man für jede Programmfunktion einen Test schreibt, der diese Funktion überprüft. In der reinen TDD-Lehre schreibt man diesen Test vor dem eigentlichen Programmieren. Ja, man hat initial mehr Aufwand. Aber danach kann man alle Tests durchlaufen lassen und sieht, dass die Applikation genau so funktioniert, wie man es sich vorgestellt hat. Der wirkliche Vorteil stellt sich aber erst nach ein paar Wochen oder Monaten ein, wenn man sich das Projekt wieder mal vornimmt und eine Erweiterung oder Veränderung schreibt. Dann kann man recht gefahrlos den Code verändern und danach die Funktionsweise anhand der Tests überprüfen. Es gibt dann kein „hmm … das ist jetzt dumm gelaufen, aber an diese Besonderheit habe ich nicht gedacht“ mehr.

Der Vorteil von TDD zeigt sich aber oft schon beim ersten Schreiben eines Programmes. Oft entlarven Tests Flüchtigkeitsfehler, die sonst erst sehr viel später auffallen würden.

Dieses Kapitel ist ein Kurzüberblick zum Thema Test-Driven-Development mit Rails. Wenn Sie Blut geleckt haben, werden Sie sicher noch tiefer einsteigen wollen. In der offiziellen Rails-Doku können Sie unter http://guides.rubyonrails.org/testing.html tiefer eintauchen.