Zu einer gegebenen Funktion (ein Sortieralgorithmus) soll ein Kontrollflussgraph erstellt werden, die McCabe-Zahl berechnet werden (beides optional), die Überdeckungsmetriken für einen bestehenden Test berechnet werden, weitere Tests aus Whitebox-Sicht ergänzt werden und alles mit einem Code-Coverage-Tool implementiert werden.
Die Leitfragen umfassen Grundlagen zur Testfallerstellung nach Whitebox-Systematik (Überdeckungstests) und Vergleiche der unterschiedlichen Überdeckungsmetriken zum Überprüfen des Grundwissens.
Übungsaufgabe zur Whitebox-Testfall-Erstellung und Berechnung der Codeüberdeckung am Beispiel einer „Rabatt“-Funktion.
Beispielfragen rund um Testgetriebene Entwicklung (_Testdriven Development_, TDD), Testfallerstellung aus Whitebox- und Blackbox-Systematik.
Leitfragen zum Überprüfen des Verständnisses von Testgetriebener Entwicklung (Testdriven Development, TDD).
Übungsaufgaben zur Erstellung von Testfällen nach Blackboxsystematik für eine Methode, die Punkte in einem String zählt.
Übungsaufgaben zur Erstellung von Testfällen nach Blackboxsystematik für eine Methode, die Division mit Rest vornimmt (wie in der Grundschule).
Übungsaufgabe zur Erstellung von Blackbox-Testfällen zu einer Funktion, die Guthaben/Soll eines Kontos verzinst
Kleine Übungsaufgaben zur Erstellung von Testfällen nach Blackboxsystematik für eine Methode, die die Anzahl der einzurichtenden Klassen berechnen soll.
Übungsaufgaben zur Erstellung von Testfällen nach Blackboxsystematik für eine Methode, die die IHK-Abschlussnote berechnet. Es werden systematisch Äquivalenzklassen und Grenzwerte bestimmt und der Algorithmus mit Pseudocode beschrieben.
Zu einer gegebenen Funktion (Versandkostenrechner) soll ein Kontrollflussgraph erstellt werden, die McCabe-Zahl berechnet werden (beides optional), die Überdeckungsmetriken für einen bestehenden Test berechnet werden, weitere Tests aus Whitebox-Sicht ergänzt werden und alles mit einem Code-Coverage-Tool implementiert werden.
Leitfragen und Übungsaufgaben zum Themengebiet Blackbox-Testfallerstellung, Whitebox-Metriken, Testgetriebene Entwicklung.
Ohne Test-Duplikate ist es oft nicht möglich, ein einzelnes Modul zu testen. Abhängigkeiten machen sonst jeden Unit-Test zum Integrationstest. Wir lernen Mocks und Stubs kennen, und dabei – wie aus Versehen – den Unterschied zwischen zustandsbasierten und verhaltensbasierten Unittests. Am Beispiel Mockito/jUnit…
Die Spezifikation sagt uns vor der ersten Zeile Code eines neuen Programmblocks, wie dieser sich verhalten soll. Wir können im Vorhinein für mögliche Eingabewerte das Resultat unseres Codeblocks bestimmen. Die systematische Ermittlung und Dokumentation dieser Eingabewert/Resultat-Kombinationen durch Äquivalenzklassenbildung und Grenzfallanalyse mündet in „Blackbox“-Testfällen.
Wir wollen uns jetzt im Kreis drehen: Ziel definieren – umsetzen – aufräumen. In kleinen Schritten. So lange, bis das Programm fertig ist. Diese Technik nennt sich Testgetriebene Entwicklung, dazu benötigen wir das Testframework `pytest` und wenige Minuten Zeit. Nebenbei lernen wir auch noch Coding-Conventions kennen.
Das Maven-Projekt wird so konfiguriert, dass nach jedem Unit-Test-Durchlauf die Überdeckungstestmetriken gespeichert und als Report aufbereitet werden.
Die zentralen CRUD-Funktionen des Repositories werden getestet. Dazu wird die given-when-then-Methodik verwendet und in jUnit jeweils Testmethoden implementiert.
Wenn die grundlegenden Testfälle gegen die Anforderungen (aus Blackbox-Sicht) erstmal erstellt sind ist es an der Zeit, die Testgüte zu messen und gegebenenfalls darauf basierend weitere Tests zu erstellen.
