6 Gründe, warum Tests alleine nicht ausreichen

Redaktion JAXenter

© Shutterstock.com/Evlakhov Valeriy

„Testing shows the presence, not the absence of bugs“. Dieser Aussage des 2002 verstorbenen niederländischen Programmierers Edsger Wybe Dijkstra stimmt der Programmierer Neill Mitchell auf seinem Blog vollumfänglich zu: Test Suites können seiner Ansicht nach zwar eine gewisse Sicherheit, aber niemals eine Garantie in Sachen Bugs geben.

Die Gründe hierfür fasst Mitchell in insgesamt sechs Punkten zusammen:

1) Die Test Suite deckt nicht den gesamten Code ab

Ab einer gewissen Größe der Codebasis ist es sehr schwer, alle Zeilen abzudecken. Die Gründe hierfür sind vielfältig: So stellen Tests eine ressourcenintensiv Aktivität dar und nur wenige Projekte verfügen über die für umfassende Tests notwendige Manpower. Des Weiteren gestaltet sich beispielsweise das Testen von Grenzfällen generell nicht einfach; das Testen von Fehlerbedingungen ist nochmals ungleich schwerer.

2) Die Test Suite deckt nicht alle möglichen Wege durch den Code ab

Gesetz den unwahrscheinlichen Fall, die Test Suite würde alle Codezeilen abdecken, so ist dies im Hinblick auf sämtliche möglichen Wege durch den Code rechnerisch fast unmöglich.

3) Ein Teil des Codes bleibt unsichtbar

Selbst wenn man den kompletten Quellcode abdecken könnte, besteht laut Mitchell immer noch das Problem, dass der Compiler die Anstrengungen torpedieren kann, beispielsweise dann, wenn er nach einer Transformation auf nicht definiertes Verhalten stößt (gängig in C/C++-Programmen), daraufhin Modifikationen am Code vornimmt und ihn auf diese Weise zerschießt. Der Quellcode mag in einem solchen Fall zwar getestet sein – der vom Compiler generierte allerdings nicht.

4) Funktionen haben große Inputs

Das Testen von Funktionen geschieht in der Regel durch Bereitstellung des Inputs und Beobachtung des Outputs. Dabei ist der Inputraum gewöhnlich zu groß für eine Aufzählung. Insbesondere wenn Strings und Arrays ins Spiel kommen werden Aufzählungen unausführbar. Stichprobentests können in diesem Zusammenhang zwar hilfreich sein, sind aber kein Allheilmittel.

5) Funktion ist nicht gleich Funktion

Beim Testen von Funktionen besteht das Problem, dass Funktion nicht gleich Funktion ist. Zum Beispiel können sich Funktionen, die einen internen Cache haben, sich unter Parallelität unterschiedlich verhalten, insbesondere dann, wenn wenn der Cache nicht richtig verwaltet wird.

6) Performance-Tests sind knifflig

Zahlen zu den in Anspruch genommenen Ressourcen können je nach Testlauf höchst unterschiedlich ausfallen, vor allem dann, wenn die Tests auf geteilter Hardware ausgeführt werden oder Parallelität nutzen. Auch praktisch jede Änderung in den Abhängigkeiten hat Einfluss auf den Ressourcenverbrauch.

Eine mögliche Lösung?

Code, so Mitchell, sollte immer so intensiv wie irgend möglich getestet werden. Einige der angesprochenen Probleme kann man seiner Ansicht nach zwar zumindest abmildern, wenn man auf funktionale Sprachen wie Haskell zurückgreift. Allerdings, so Mitchell weiter, solle man sich stets vergegenwärtigen, dass Programme ab einer gewissen Größe unweigerlich blinde Flecken und unentdeckte Bugs aufweisen.

Aufmacherbild: Keyboard with test button von Shutterstock / Urheberrecht: Evlakhov Valeriy

Geschrieben von
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: