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.
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].