Tests

Testgetriebene Entwicklung ist eine gute Sache, gar keine Frage. Gerade heutzutage, wo Projekte von vielen Entwicklern gemeinsam geschrieben werden und wo agiles Entwickeln Einzug gehalten hat, kann das Schreiben von Tests sehr nützlich sein.

Trotzdem sollte man immer wieder überlegen, ob bei einem Projekt Tests sinnvoll sind und, wenn ja, in welchem Maße. Es ist ja nicht gerade so, dass Tests keine Kosten verursachen würden. Ihren betriebswirtschaftlichen Nutzen können sie oft erst über die hoffentlich lange Gebrauchsdauer der Software ausspielen. Viele Projekte werden heutzutage jedoch schneller wieder verworfen, als man denkt, und dienen vielleicht nur als Übergangslösung. Hier sollten Webentwickler sicher öfter betriebswirtschaftlich handeln.

Um den Vorteil von Tests nämlich nicht ins Gegenteil zu verkehren, sollte immer gut überlegt werden, was man denn genau testen möchte. Es gibt Entwickler, die rigoros alles testen, was ihnen unter die Finger kommt.

Viel wichtiger ist jedoch zum einen, diejenigen Dinge zu testen, die – falls sie zu Bruch gehen – Fehler produzieren, die schwer zu finden sind und einen großen Schaden anrichten können. Und zum anderen sollten diese Tests dann auch so geschrieben sein, dass sie an den richtigen Stellen kaputt gehen.

Ist es zum Beispiel wichtig, dass ich die korrekte Beschriftung eines Buttons automatisiert teste? Im ganzen Projekt? Würde ich diesen Fehler nicht auch anders bemerken? Wie hoch ist der Aufwand des Tests und wie hoch wären die Kosten eines Fehlers? Diese Rechnung wird leider viel zu selten aufgemacht.

Wenn man bedenkt, dass vor noch nicht so langer Zeit kaum getestet worden ist und trotzdem ganz sinnvolle Programme erstellt worden sind, so ist das dogmatische Verfechten einer 100%-Testabdeckung zumindest zweifelhaft. Bei vielen Webentwicklern ist das Testing leider zum Selbstzweck verkommen und obige Überlegungen werden als Blasphemie verteufelt.