diff --git a/Lerntagebuch.md b/Lerntagebuch.md
index ada95d9..b666271 100644
--- a/Lerntagebuch.md
+++ b/Lerntagebuch.md
@@ -225,3 +225,32 @@ egal ob andere Tests modifiziert wurden. Um dies zu erreichen,
 werden Einheiten unabhängig von anderen durch Setzen von Stubs, Fakes oder Mocks gemacht.
 
 ### Kritik
+
+---
+
+## SU 09 (09.01.2024)
+
+### Lernziel
+ - Motivation von automatisierten Test & nützliche Nebeneffekte bei Qualitätskosten
+ - Die geschenkte Vertrauenswürdigkeit von automatisierten Tests & technischen Hindergründe
+ - Drei Versionen von zeitlich getesteten Codes, sowie deren Nach- & Vorteile
+ - key performance indicator (KPI) und Test Driven Development (TDD) und deren Testabdeckung
+ - inkrementelle Entwicklung des Codes bei TDD und der Vorteil beim Verhindern des Flows
+ - Drei schrittige Vorgehensweise: Neuer Test, Transformation & Refactoring
+
+### Erkenntnis
+Für das Gruppenprojekt habe ich diese Woche die Vorgehensweise von Test Driven Development (TDD) kennengelernt.
+Diese ist eine der drei Formen des zeitnahen Testens beim Coden (Code first, Test first & TDD).
+Das dafür gewählte automatisierte Testen bringt per se außerdem ein Kriterium des RTFM mit: Vertrauenswürdigkeit.
+
+### Wiederholung
+Das TDD wird in der Theorie in drei bis vier Phasen unterteilt. Die erste sind die Anforderungen.
+Dabei werden die nächst einfach zu implementierbaren Anforderungen ausgesucht.
+Als nächstes kommt das Schreiben eines neuen Tests. Dabei wird jedes Mal wenn ein Fehler ensteht in die nächste Phase gewechselt.
+Die Transformationsphase besteht aus dem grundsätzliche Coden bis der Fehler verschwunden ist.
+Dabei soll so wenig codiert werden wie möglich. Im Anschluss kommt das Refactoring.
+Hier wird die Geschäftslogik nicht angefasst, aber der Code angepasst, dass er besser lesbar ist.
+Diese letzten drei Schritte werden solange ausgeführt bis die ausgesuchten Anforderungen erfüllt sind
+und man sich neuer Anforderungen zuwenden kann.
+
+### Kritik