Themen

Motivation: zwingende Voraussetzung für Wissenschaftlichkeit

Probleme mit der Überprüfung von Software

Arten von Tests

Strategien für die Überprüfung von Software

Glossar

PDF

Kapitel bei Springer

https://link.springer.com/chapter/10.1007/978-3-662-71607-6_18

• Überprüfung ist ein Kernaspekt sowohl von Wissenschaft
  als auch von moderner Softwareentwicklung.
• Überprüfung wissenschaftlicher Software ist entscheidend,
  weil sie den Erkenntnisgewinn selbst betrifft.
• Der größte Teil wissenschaftlicher Software ist
  unzureichend oder gar nicht getestet.
• Tests können nur die Existenz von Fehlern beweisen,
  nicht deren Abwesenheit.
• Tests sollten so früh wie möglich, so oft wie möglich und
  so automatisiert wie möglich durchgeführt werden.

Nachvollziehbarkeit und Überprüfbarkeit sind Kernaspekte der Wissenschaften. Da Wissenschaft sich zunehmend digitaler Werkzeuge – wissenschaftlicher Software – bedient, ist es wichtig, die Zuverlässigkeit dieser Werkzeuge überprüfen zu können und entsprechend durch Tests sicherzustellen.

Während mittlerweile in der professionellen Softwareentwicklung weitgehend Einigkeit darüber herrscht, dass Tests und Testbarkeit essentielle Voraussetzungen für qualitativ hochwertige und insbesondere zuverlässige Software sind, wird dieser Aspekt in der wissenschaftlichen Softwareentwicklung noch weitgehend ignoriert. Die Folge mag im Gegensatz zu kommerzieller Software nicht wirtschaftlicher Natur sein – dafür rührt sie an die Grundlagen der Wissenschaft: Die meiste in der Wissenschaft zum Erkenntnisgewinn eingesetzte und von Forscherinnen und Forschern selbst geschriebene Software ist weder gestestet noch testbar und damit schlicht von unbekannter Qualität.

Wer den Ansprüchen der Wissenschaft genügen will und Software zum wissenschaftlichen Erkenntnisgewinn schreibt und einsetzt, wird um eine Überprüfbarkeit dieser Software nicht umhin kommen. Das setzt ein Bewusstsein für die Bedeutung von Tests und Strategien für das Schreiben von Tests sowie generell von überprüfbarer Software voraus. Fehlerfreiheit von Software ist dabei eine Illusion, Tests dienen dazu, Fehler zu finden und die Abwesenheit einmal gefundener Fehler sicherzustellen. Die Überprüfung von Software ist dabei ein systematisches Unterfangen mit großen Ähnlichkeiten zum Vorgehen in den Wissenschaften.

Diese Fragen dienen der persönlichen Beschäftigung mit der Thematik, es werden aber keine Antworten zur Verfügung gestellt.

• Welche Bedeutung kommt Tests insbesondere im Kontext von Software für wissenschaftliche Datenauswertung zu?
• Welche grundsätzlichen Probleme mit Tests von Software halten viele Programmierer davon ab, ihre Software (ausreichend zu testen)?
• Neben den grundsätzlichen Problemen gibt es noch eine ganze Reihe praktischer Aspekte. Welche ließen sich aufführen?
• Warum ist die vollständige Testbarkeit selbst sehr einfacher Programme in der Regel praktisch nicht durchführbar? Wie kann man dieses Problem umgehen?
• Was ist die wichtigste Regel im Umgang mit Tests?
• Wie sollten Sie mit Testcode umgehen? Was lässt sich bezüglich Codequalität sagen? Warum ist Lesbarkeit für Tests von besonderer Bedeutung?
• Welchen Vorteil haben Tests potentiell gegenüber (klassischer) Dokumentation?

Eine kommentierte und handverlesene Liste mit weiterführender Literatur zum Thema. Die Auswahl ist zwangsläufig subjektiv.

Eine sehr auf strukturierte Programmierung und Tests ohne spezifische Test-Frameworks zugeschnittene Behandlung der Thematik mit vielen guten Tipps für den Alltag findet sich in Kapitel 6 in [Kernighan, 1999Kernighan, Brian W.; Pike, Rob (1999): The Practice of Programming, Addison Wesley, Boston].

Eine kompakte Übersicht über das Testen von Software und Strategien, die sich auf viele Projekte anwenden lassen, ist der Artikel von Whittaker [Whittaker, 2000Whittaker, James A. (2000): What is software testing? And why is it so hard?, IEEE Softw. 17:70-79]. Viele gute Tipps für die Praxis finden sich in den Abschnitten 34 und 43 von [Hunt, 1999Hunt, Andrew; Thomas, David (1999): The Pragmatic Programmer, Addison-Wesley, Boston]. Damals waren Tests und war testgetriebene Entwicklung noch ganz in den Anfängen. Entsprechend haben sie in der Neuauflage ihres Buches [Thomas, 2020Thomas, David; Hunt, Andrew (2020): The Pragmatic Programmer, Addison-Wesley, Boston] die Thematik erweitert.

Eine umfassendere (und aktuellere) Darstellung mit dem Fokus auf Tests durch Softwareentwickler ist Kapitel 22 in [McConnell, 2004McConnell, Steve (2004): Code Complete. A practical handbook of software construction, Microsoft Press, Redmond, Washington]. Sehr viel mehr auf Unittests und testgetriebene Entwicklung fokussiert sind Kapitel 4 in [Martin, 2003Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey] und Kapitel 9 in [Martin, 2008Martin, Robert C. (2008): Clean Code. A Handbook of Agile Software Craftmanship, Prentice Hall, Upper Saddle River, New Jersey].

Die McCabe-Metrik zur Quantifizierung der Komplexität von Software über die Anzahl unabhänger Pfade wurde von ihrem Namensgeber eingeführt [McCabe, 1976McCabe, Thomas J. (1976): A complexity measure, IEEE Trans. Softw. Eng. 2:308-320] und wird u.a. in [McConnell, 2004McConnell, Steve (2004): Code Complete. A practical handbook of software construction, Microsoft Press, Redmond, Washington] (S. 457ff.) besprochen.

Die Bedeutung von Tests gerade für Software, die für den wissenschaftlichen Erkenntnisgewinn eingesetzt wird, wird in [Scopatz, 2015Scopatz, Anthony; Huff, Kathryn D. (2015): Effective Computation in Physics, O'Reilly, Sebastopol] (Kap. 18) ausführlich betont. Siehe dazu auch u.a. [Merali, 2010Merali, Zeeya (2010): ...why scientific programming does not compute, Nature 467:775-777].

• Hunt, Andrew; Thomas, David (1999): The Pragmatic Programmer, Addison-Wesley, Boston
• Kernighan, Brian W.; Pike, Rob (1999): The Practice of Programming, Addison Wesley, Boston
• Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey
• Martin, Robert C. (2008): Clean Code. A Handbook of Agile Software Craftmanship, Prentice Hall, Upper Saddle River, New Jersey
• McCabe, Thomas J. (1976): A complexity measure, IEEE Trans. Softw. Eng. 2:308-320
• McConnell, Steve (2004): Code Complete. A practical handbook of software construction, Microsoft Press, Redmond, Washington
• Merali, Zeeya (2010): ...why scientific programming does not compute, Nature 467:775-777
• Scopatz, Anthony; Huff, Kathryn D. (2015): Effective Computation in Physics, O'Reilly, Sebastopol
• Thomas, David; Hunt, Andrew (2020): The Pragmatic Programmer, Addison-Wesley, Boston
• Whittaker, James A. (2000): What is software testing? And why is it so hard?, IEEE Softw. 17:70-79