From 77dda34a866ea304d7d045e51738e362b0fc477a Mon Sep 17 00:00:00 2001 From: Saba Fazlali Date: Sun, 14 Jan 2024 23:19:01 +0100 Subject: [PATCH] 9. Vorlesung --- Lerntagebuch.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/Lerntagebuch.md b/Lerntagebuch.md index 47baca6..b7ed2c7 100644 --- a/Lerntagebuch.md +++ b/Lerntagebuch.md @@ -306,3 +306,31 @@ Wir müssen sauberen Code schreiben, indem wir auf der Grundlage klarer Schnitts Unittests sind wie ausführbare Dokumentation, prüfen beobachtbares Verhalten des Codes durch Testen von Rückgabewerten und Kommunikation mit anderen Einheiten, setzen klare Erwartungen in einzelnen Tests und verhindern ungewollte Änderungen. Unabhängigkeit beim Schreiben von Tests bedeutet: Jeder Test kann einzeln ausgeführt werden und kein Test schafft Vorbedingungen für nachfolgende Tests. Tests können in beliebiger Reihenfolge ausgeführt werden. + +___ + +## 9. Vorlesung (09.01.2024) + +### Lernziel +- Merkmal eines guten Unittests (FIRST RTFM) + - vertrauenswürdig (trustworthy): + - Ausführung des Produktivcodes + - Fehlschlag des Tests aus dem richtigen Grund + - zeitnah (timely): + - code first + - test first + - TDD (Test und Code gleichzeitig) +- Unittests: die häufigsten automatisierten Tests +- Test Driven Development (TDD): der geeignetste Ansatz zur Erstellung von Unittests +- TDD führt zu hoher Testabdeckung (nicht zu 100%, realistisch 70% - 90%) +- TDD führt zu 100% Anforderungsabdeckung! +- einige Testfälle für Conways Spiel des Lebens als Beispiel + +### Erkenntnis + +Wir betrachten den TDD Microcycle: Wir schreiben einen neuen Test, gerade so viel, dass er fehlschlägt. (nicht zu kompilieren ist fehlgeschlagen) Dann schreiben wir gerade genug Produktionscode, um den Test zu erfüllen. Dann verbessern wir den Code (Produktion und Test), ohne einen Test zu brechen und ohne neue Funktionalität (Geschäftslogik) hinzuzufügen. Der beste Zeitpunkt für eine Commit ist nach dem Refactoring. + +### Wiederholung + +In Baby-Schritten vorgehen bedeutet, Veränderungen in möglichst kleinen Schritten vorzunehmen. +Test Driven Development ist in erster Linie dazu da, eine hohe Testabdeckung zu erreichen. Damit ist nicht eine 100%ige Testabdeckung gemeint sondern 70-90 % in der Realität.