Gute Software braucht gute Dokumentation – ohne unnötigen Aufwand. Eine erste Anlaufstelle ist häufig die `Readme.md`-Datei in git-Repositorys. Aber: für wen schreibe ich die eigentlich? Was sollte, was muss da rein? Wie formatiere ich die Readme-Datei mit Markdown?
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.
