Leitfragen zu testgetriebener Entwicklung (TDD)
https://bildung.social/@oerinformatik/109287342438127241
https://oer-informatik.de/tdd-leitfragen
tl/dr; (ca. 90 min Bearbeitungszeit): Leitfragen zum Überprüfen des Verständnisses von Testgetriebene Entwicklung (Testdriven Development, TDD). (Zuletzt geändert am 06.12.2023)
Die Aufgaben beziehen sich auf die Inhalte der folgenden Blogposts:
Leitfragen Testgetriebene Entwicklung:
- Was versteht man unter Testgetriebener Entwicklung (TDD)?
Bei Testgetriebener Entwicklung wird zunächst ein Test erstellt, der einen Teil der Spezifikation überprüft und erst im zweiten Schritt die zugehörige Implementierung, die den Test bestehen lässt.
- Welche drei Phasen gibt es in der Testgetriebenen Entwicklung, wie werden sie genannt, und welche Aufgaben hast Du als Entwicker*in in dieser Phase?
TDD umfass diese drei sich permanent wiederholenden Phasen: * Red: Erstelle einen Test, der einen kleinen (!) Bereich der Spezifikation umfasst. Dieser soll zunächst scheitern. * Green: Implementiere gerade so viel Code, damit der zuvor erstellte Test bestanden wird. * Refactor: Verbessere - wenn nötig - den Code des Tests und der Implementierung, ohne die Funktionalität zu verändern. 
- Testgetriebenen Entwicklung wurde v.a. im Umfeld eines bestimmten Vorgehensmodells bekannt. Welches Vorgehensmodell ist dies?
Testgetriebene Entwicklung wurde v.a. durch Kent Beck bekannt, der es im Rahmen des Vorgehensmodells extreme programming (XP) entwickelt hat.
- In der Softwareentwicklung verwenden wir bei der Problemlösung häufig die Strategien Atomisieren (Aufteilen in kleinere, lösbare Probleme) und Abstrahieren (Ähnlichkeiten zu bekannten Problemlösungen finden). Beschreibe auf welche Art Testgetriebene Entwicklung eine dieser Strategien nutzt.
Testgetriebene Entwicklung geht davon aus, dass jeweils nur kleine Abschnitte der Spezifikation getestet und entwickelt werden. Durch diese Kleinschrittigkeit ist der Fokus auf ein Teilproblem gesetzt. Die anderen bereits realisierten Abschnitte geraten durch die dafür bereits realisierten Tests jedoch nicht in Vergessenheit, sondern werden von der Testsuite weiterhin abgedeckt. Das Lösen von kleinen Teilen der Spezifikation als zentraler Bestandteil von TDD steht für die Atomisierung von Problemstellungen.
- Zur Testfallerstellung für Software können Whitebox- und Blackbox-Verfahren genutzt werden. Beschreibe, welches dieser beiden Verfahren bei der Testgetriebenen Entwicklung eingesetzt wird - und warum das jeweils andere nicht genutzt wird.
Bei der Testgetriebenen Entwicklung entsteht der Test vor der eigentlichen Implementierung. Daher können diese Tests nur gegen die Spezifikation erstellt werden, also aus Blackboxsicht. Whitebox-Tests könnten im Nachgang aufgrund der Abdeckungsmetriken ergänzt werden, das ist jedoch nicht (mehr) Bestandteil des TDD-Zyklus.
- Für ein Projekt, an dem Ihr Betrieb seit einem halben Jahr arbeitet, wurden für den letzten Sprint das Sprintziel “Code mit Unit-Tests abdecken” festgelegt. Die meisten Module besitzen bislang nur wenige Integrations- und keinerlei Unittests. Nach Abschluss des Sprints konnte das Team tatsächlich eine Codeüberdeckung von 100% erreichen. Wurde das Projekt nach dieser Phase testgetrieben entwickelt? Falls nein: Welche Änderungen wären erforderlich, damit es als “testgetrieben entwickelt” bezeichnet werden kann?
Der Ablauf, Tests erst während oder nach der Implementierung zu erstellen widerspricht den Grundsätzen der Testgetriebenen Entwicklung. Testgetrieben wäre das Vorgehen nur dann, wenn für kleine Spezifikationsabschnitte zunächst ein Test, danach der zugehörige Code implementiert würde, gemäß TDD-Zyklus.
- Ab welchem Überdeckungsgrad darf man von “testgetriebener Entwicklung” sprechen?
Der Überdeckungsgrad hat keinerlei bezug zur Testgetriebenen Entwicklung. Daher gibt es auch keine Festlegung, welche Testabdeckung erreicht werden soll. Die Überdeckungsmetriken können genutzt werden, um nach der Erstellung von Blackboxtests und nach der darauf folgenden Implementierung Hinweise darauf zu erhalten, welche Testfälle man ggf. noch ergänzen sollte.
- Bei testgetriebener Entwicklung wird in Phasen vorgegangen. Benenne alle Phasen, in denen der eigentliche Programmcode angepasst wird!
In den Phasen Green und Refactor wird der Programmcode bearbeitet, wobei nur in Green neue Funktionalitäten hinzugefügt werden.
- Benenne alle Phasen, in denen der Testcode angepasst wird!
In den Phasen Red und Refactor wird der Testcode bearbeitet, wobei nur in Red neue Tests für Funktionalitäten entstehen.
Weiter Übungsaufgaben
Links zu weiteren Übungsaufgaben finden sich über das Menü oder am Ende des Artikels zu Blackbox-Tests
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Leitfragen zu testgetriebener Entwicklung (TDD)” von Hannes Stein, Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/tdd-leitfragen veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/qs/blackboxtest. Stand: 06.12.2023.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
