Themen

Grundüberlegungen zur Testautomatisierung

Grundregeln testgetriebener Entwicklung

Auswirkungen testgetriebener Entwicklung

Wichtige Aspekte von Tests

Folien

PDF

Glossar

PDF

Video

MP4

Hinweis: Der Webcast wurde mit Tiny Webcasts for Lecture(r)s erstellt.

• Automatisierung ist Voraussetzung für häufiges Testen –
  und für Refactoring und Verbesserung der Codequalität.
• Testautomatisierung hat tiefgreifenden Einfluss
  auf den Entwurf des zu testenden Codes (u.a. Modularität).
• Testgetriebene Entwicklung stellt die Reihenfolge auf den Kopf
  und sorgt für hohe Testabdeckung.
• Hohe Testabdeckung durch automatisierte Tests
  erhöht das Vertrauen in Software.
• Testgetriebene Entwicklung führt zu Tests,
  die den Code und seine Spezifikationen dokumentieren.

Diese Fragen dienen der persönlichen Beschäftigung mit der Thematik, werden aber nicht separat in der Vorlesung besprochen.

• Warum sollten Tests automatisiert werden? Was genau sollte automatisiert werden?
• Wie sieht die Grundstruktur eines automatisierten (Unit)Tests aus?
• Nennen Sie die Grundregeln und das generelle Vorgehen testgetriebener Entwicklung.
• Welche Strategien gibt es, einen Test zum Erfolg zu führen? Wann bietet sich welche Strategie an?
• Wie umgeht testgetriebene Entwicklung (test-driven development, TDD) das Problem der unendlichen Regression der Tests von Tests?
• Was macht einen guten Test aus? Warum ist die Codequalität bei Tests so wichtig?

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

Testautomatisierung ist ein vergleichsweise altes Thema und als solches unabhängig vom verwendeten Programmierparadigma. Gute allgemeine Hinweise finden sich in Kapitel 6 in [Kernighan, 1999Kernighan, Brian W.; Pike, Rob (1999): The Practice of Programming, Addison Wesley, Boston]. Auch Whittaker [Whittaker, 2000Whittaker, James A. (2000): What is software testing? And why is it so hard?, IEEE Software 17:70-79] diskutiert Testautomatisierung in einem breiteren Kontext. Hunt und Thomas [Hunt, 1999Hunt, Andrew; Thomas, David (1999): The Pragmatic Programmer, Addison-Wesley, Boston] (Abschnitt 43) führen die Bedeutung der Automatisierung von Tests sehr deutlich vor Augen.

Eine sehr lesbare Einführung mit dem Fokus auf Programmierung in der Wissenschaft, Python und ein einfach nutzbares Test-Framework findet sich in Kapitel 18 von [Scopatz, 2015Scopatz, Anthony; Huff, Kathryn D. (2015): Effective Computation in Physics, O'Reilly, Sebastopol].

Das vielleicht einflussreichste Buch über testgetriebene Entwicklung ist Kent Becks flammendes Plädoyer inklusive praktischer Beispiele [Beck, 2003Beck, Kent (2003): Test-Driven Development By Example, Addison-Wesley, Boston]. Aber auch Robert C. Martin betont dessen Bedeutung immer wieder, u.a. in [Martin, 2008Martin, Robert C. (2008): Clean Code. A Handbook of Agile Software Craftmanship, Prentice Hall, Upper Saddle River, New Jersey] (Kapitel 9) und [Martin, 2003Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey] (Kapitel 4). Eine sehr kurz gefasste, lesbare und ausgewogene Beschreibung ist [Martin, 2007Martin, Robert C. (2007): Professionalism and test-driven development, IEEE Software 24:32-36]. Ein sehr schönes, ausformuliertes Beispiel einer Pair-Programming-Sitzung und der testgetriebenen Entwicklung eines Spiels liefert Kapitel 6 in [Martin, 2003Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey].

Die Qualität des Testcodes ist mindestens genauso wichtig wie die von Produktivcode. Allerdings gelten für Testcode zumindest teilweise unterschiedliche Kriterien. Eine gute und eher kurze Einführung in die Kunst, gute Unittests zu schreiben, ist [Osherove, 2014Osherove, Roy (2014): The Art of Unit Testing, Manning, Shelter Island]. Sehr viel ausführlicher ist [Meszaros, 2007Meszaros, Gerard (2007): xUnit Test Patterns, Addison-Wesley, Boston].

Einen guten Überblick über die Erstellung komplexer (realer) Systeme mittels testgetriebener Entwicklung neben sehr vielen wertvollen Tipps zum Entwurf objektorientiert programmierter Systeme liefert [Freeman, 2010Freeman, Steve; Pryce, Nat (2010): Growing Object-Oriented Software, Guided by Tests, Addison Wesley, Upper Saddle River, New Jersey]. Das weit verbreitete Problem, mit einer Codebasis arbeiten zu müssen, die nicht (ausreichend) getestet ist (legacy code), wird im Detail von [Feathers, 2005Feathers, Michael C. (2005): Working Effectively with Legacy Code, Prentice Hall, Upper Saddle River, New Jersey] diskutiert, inklusive entsprechender Lösungsansätze.

Für eine detaillierte Diskussion von Gleitkommazahlen und ihrer Repräsentation in Hard- und Software, die insbesondere für den Vergleich numerischer Werte in automatisierten Tests von Belang ist, vgl. den Artikel von Goldberg [Goldberg, 1991Goldberg, David (1991): What every computer scientist should know about floating-point arithmetic, ACM Computing Surveys 23:5-48]. Eine etwas kürzere Einführung liefert Moler: [Moler, 2004Moler, Cleve B. (2004): Numerical Computing with MATLAB, SIAM, Philadelphia], Kapitel 1.

• Beck, Kent (2003): Test-Driven Development By Example, Addison-Wesley, Boston
• Feathers, Michael C. (2005): Working Effectively with Legacy Code, Prentice Hall, Upper Saddle River, New Jersey
• Freeman, Steve; Pryce, Nat (2010): Growing Object-Oriented Software, Guided by Tests, Addison Wesley, Upper Saddle River, New Jersey
• Goldberg, David (1991): What every computer scientist should know about floating-point arithmetic, ACM Computing Surveys 23:5-48
• 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. (2007): Professionalism and test-driven development, IEEE Software 24:32-36
• Martin, Robert C. (2008): Clean Code. A Handbook of Agile Software Craftmanship, Prentice Hall, Upper Saddle River, New Jersey
• Meszaros, Gerard (2007): xUnit Test Patterns, Addison-Wesley, Boston
• Moler, Cleve B. (2004): Numerical Computing with MATLAB, SIAM, Philadelphia
• Osherove, Roy (2014): The Art of Unit Testing, Manning, Shelter Island
• Scopatz, Anthony; Huff, Kathryn D. (2015): Effective Computation in Physics, O'Reilly, Sebastopol
• Whittaker, James A. (2000): What is software testing? And why is it so hard?, IEEE Software 17:70-79

Die heute von vielen Programmiersprachen verwendete Variante, Gleitkommazahlen darzustellen, ist in der Norm IEEE 754 (ANSI/IEEE Std. 754-1985) spezifizert. Jede Zahl wird durch 64 Bit (8 Byte) repräsentiert, was auch als „doppelte Genauigkeit“ bezeichnet wird. Ein paar Details zur doppelten Genauigkeit und zur Norm IEEE 754 finden sich in der (deutschsprachigen) Wikipedia.

Weitere Details und Beispiele, die die generelle Art der Codierung von Gleitkommazahlen beschreiben, finden sich im Buch Numerical Computing with MATLAB von Cleve Moler, dem Gründer von MathWorks (der Firma hinter Matlab). Die entsprechenden Passagen finden sich im ersten Kapitel des Buches. Auch wenn Moler sein Buch insgesamt aus der Sicht von Matlab schreibt, sind seine Ausführungen von allgemeinem Nutzen und auf andere Programmiersprachen übertragbar.