diff --git a/Lerntagebuch.md b/Lerntagebuch.md
index befee04..1ffc7e5 100644
--- a/Lerntagebuch.md
+++ b/Lerntagebuch.md
@@ -668,6 +668,80 @@ Aus dem Seminarischen Unterricht und dem Praxisteil kann ich das Wissen Testen d
 Tests dienen unter Anderem der Steigerung des Vertrauens in die Software. Wenn ein bestimmter Test mit bestimmten Eingabedaten bestanden wird, kann man als Programmierer darauf vertrauen, dass dieses bestimmte Szenario auch beim Kunden funktionieren wird. Und je mehr Tests, desto mehr Szenarien existieren, für die man garantieren kann, dass die Software funktioniert.
 
 
+### Kritik
+
+Keine
+
+---
+
+## SU 08 (17.12.2023) - Testautomatisierung
+
+### Lernziel
+
+Warum nicht manuell testen?
+- Diverse Gründe, hauptsächlich menschliche Fehler wie das versehentliche doppelte Testen von bestimmten Teilen
+
+Die einzigen Gründe gegen automatisiertes Testen:
+- UI-Design
+- Code ist von jemand anderem
+- Kein Wissen über automatisierte Tests
+
+Welche Tests sollte man automatisieren?
+- Tests die häufig wiederholt werden (müssen)
+- Tests die hohe Kritikalität haben → Funktionalität der Software
+- Stabile Tests → Sollten sich mit Weiterentwicklung der Software nicht groß ändern müssen
+
+Application und Module Tests
+- Testen die Zusammenarbeit der einzelnen Module der Software
+- Können über das Anwendungsinterface oder Frameworks durchgeführt werden
+- Können erst später im Entwicklungsprozess ausgeführt werden
+
+Unit Tests
+- Können sehr früh im Entwicklungsprozess ausgeführt werden
+- Stabil gegen Änderungen (anderer Units)
+- Überprüfen nur Funktionalität und das Verhalten des Codes, nicht ob ein Logikfehler im Programm vorliegt
+- Ein Test überprüft nur eine Erwartung 
+
+Bedingungen für Tests:\
+F → fast\
+I → independent\
+R → repeatable\
+S → selfevaluating\
+T → timely\
+\
+R → readable\
+T → trustworthy\
+F → fast\
+M → maintainable
+
+Bessere Unit-Tests sind möglich, wenn nach den bekannten Richtlinien programmiert wurde, z.B. SOLID und STUPID
+
+Testdoubles
+- Units von denen die zu testende Unit abhängt werden durch "Fake-Units" ersetzt
+- Verschiedene Verhalten, z.B. Stub, Fake und Mock für verschiedene Anwendungsfälle
+
+Ersetzen von Abhängigkeiten
+- Geschäftslogik und Funktionalität der Unit werden getrennt getestet
+- Man sollte Seams einbauen, um das Einspeisen von Abhängigkeiten zu ermöglichen, z.B. Setter
+
+
+Praxisübung:
+- Durchführen von Unit-Tests
+- Testname muss mit "test" anfangen
+- Prozedurname_Vorbedingung_ErwartetesErgebnis
+- arrange, act, assert oder given, when, then
+
+
+### Erkenntnis
+
+Für das Gruppenprojekt kann ich das Wissen über automatisiertes Testen mitnehmen.
+
+
+### Wiederholung
+
+Unit-Tests sollten möglichst schnell sein. Ein schneller Test kann nach jedem Speichern der Software ausgeführt werden, ohne den Developer zu nerven. Ein Richtwert ist etwa eine halbe Sekunde.
+
+
 ### Kritik
 
 Keine