@ -1087,8 +1087,6 @@ Wie kommen Fehler ins Programm und wann wirken sich diese aus? Das beschreibt di
#### Vorlesung
- Problem von manuellem Testen
- Software muss erstmal so weit sein
- Widerholbarkeit --> Aufmerksamkeit lässt nach
@ -1245,3 +1243,103 @@ In unserem Gruppenprojekt werden wir Unittests verwenden, da es sich beim Schrei
### Wiederholung
Es gibt viele Gründe angeblich keine Tests schreiben zu müssen oder zu sollen. Viele von denen sind allerdings Missverständnisse. Zu diesen gehören unter anderem die Angst, dass durch Unittests keine Fehler behoben werden. Letztendlich gibt es nur einen Grund; das fehlende Wissen sie (die Unittests) zu schreiben.
## Vorlesung vom 2023.1.9/Übung vom 2023.1.11
### Lernziel
#### Vorlesung
Test Driven Development
- Trustworthy und Timely wird geschenkt
- wird gleichzeitig geschrieben (test driven development)
- kann von einer Person gemacht werden
- kann auch mit pairprogramming gemacht werden
- beste Mittel zur Erzeugung von Tests
- code first
- zum Scheitern verurteilt, da Zeit am Ende genommen werden muss
- test first
- möglich aber nicht ideal
- technische Vertrauenswürdigkeit
- Testabdeckung
- 1. Mg wird jede Codezeile abgedeckt (Bezugspunkt für Vorlesung)
- 2. Mg alles Mg abgedeckt
- 3. Mg loops werden auch noch beachtet
- sicherstellen dass loop aufhört
- Wird als Maß für Codequalität verwendet
- kann aber auch nicht sinnvoll verwendet werden
- kein Fokus auf Qualität sondern auf Codezeilenabdeckung
- Problem
- Testdrivendevelopment (TDD)
- wird nie 100% Abdeckung erreichen
- bluecode
- code der einfach von Programmiersprache gefordert wird aber nix bringt (oder Code der Datenstrukturen wiederspiegelt)
- wird nicht getestet
- realistisch 70-90% Abdeckung
- Vorteil TDD
- 100% Anforderungensabdeckung erfüllt (da Produktivlogik zu 100% getestet wird)
- kann aber nich gemessen werden
- Vorgehen TDD
- Arbeitsmethode keine Testmethode
- ist erster Linie Code entwickelt nicht Tests
- Formalisieren Prozess
- kleine Inkremente
- kleine Änderung weniger Fehler
- TDD hilft dabei
- verhindert Flowzustand (schreibt viel Code und schnell aber macht viele Fehler)
- durch Wechsel werden Anforderungen nicht vernachlässigt
- Am Anfang Anforderungen des Kunden und Dokument von uns was er von uns erwarten kann
- sind Grundlage für nächsten zu schreibenden Test
- suchen einfachste Anforderung raus die man entnehmen kann
- schreiben so viel Test bis er fehlschlägt
- sobald Test nicht kompiliert
- Zeile fertig schreiben
- dann wird Produktivcode geschrieben
- Phase 2:
- alles tun damit der Test so schnell wie möglich grün wird
- best practices egal
- im Anschluss
- Phase 3
- Code wird hübsch gemacht
- nur strukturelle Änderungen
- nutze IDE Tools (automatisierte Tools)
- am einfachsten Umbennung
- schauen ob Entwurfsmuster vorhanden um zu vereinfachen
- danach wieder Phase 1 (Mircocycle)
- irgendwann ist Test vollständing
- neuer Test aus den Anforderungen
- bevor Test weiter schreiben oder Refactoring
- guter Zeitpunkt zum Commiten
#### Übung
- Üben von TDD basierend auf letzter Dateien letzter Übung
- mit C Files nicht Java
- praktisches Beispiel von Mircocycles
- Wiederholung von Begriffen
### Erkenntnis
Das gleichzeitige Schreiben von Tests und Produktivcode in Form von TDD hat die meisten Vorteile bei der Entwicklung (siehe Wiederholung). Deswegen werden wir diese Methode auch bei unserem Gruppenprojekt nutzen zur Entwicklung nutzen.
### Wiederholung
Ein Vorteil von TDD ist eine 100%tige Anforderungsabdeckung durch Tests. Außerdem durch das gleichzeitige Schreiben von Produktivcode und Tests die Prinzipien Timely und Trustworthy, die als erstrebenswert gelten gleich mit erfüllt. Realistisch sind bei TDD 70-90% Codezeilenabdeckung.
fdai7783
11 months ago