Vorlesung erklaert

Lerntagebuch.md

@@ -1,253 +1,506 @@
 ## Lerntagebuch
 
-  # Mein Lerntagebuch für Programmiermethoden und -werkzeuge 
-  Das ist ein Beispiel wie ein Lerntagebuch aussehen könnte. 
-
-  ## SU 01(21.10.2021) 
-  ### Lernziel 
-  - Organisatorisches 
-  - Versionskontrollsysteme allgemein 
-  - git 
-  - Vorteile 
-  - wie lege ich ein Repository an 
-  - vim (ein paar alltägliche Befehle) 
-  
-  ### Erkenntnis 
-  Versionskontrolle werden wir im Projekt einsetzen, um
-  zu jeder Zeit den Entwicklungsstand einzusehen und paralleles Arbeiten an Dateien zu ermöglichen. Sollten Probleme an der Software auftreten, können wir zu einem funktionierenden Stand wechseln und durch das Commit-Log die Ursache ausfindig machen.
-  Außerdem kann ich als Developer mit den gelernten vim-Befehlen vor den anderen flexen. 
-
-  ### Kritik 
-  `git status` zeigt mir einen groben Zustand meines Git-Repositorys an. Manchmal werden Dateien  oder Verzeichnisse dort rot oder grün angezeigt. Die grünen
-  Dateien verschwinden von der Ausgabe, wenn ich `git commit`
-  ausführe. Rote Dateien werden mit `git add` grün. 
-
-  ### Mitteilung
-  an die Dozierenden Da dieser Punkt optional ist, lasse ich ihn
-  weg. Aber wenn mich irgendwas stört oder begeistert, kann ich es
-  hier anmerken.
-
-  ## Uebung 01 (27.10.2022)
-  ### Lernziel
-  - SSH-Zugriff-zum-git-server-konfigurieren
-    - SSH key pair generieren
-    - oeffentlichen SSH key im Repository eintragen
-    - Lokale Kopie auf SSh-Zugriff umstellen
-    - Neue lokale Repositories
-    
-  ### Erkenntnis
-    - einen ssh-key erstellt
-    - öffentlichen Schlüssel zu gogs hinzugefügt
-    - Master Branch erstellt
-  
-  ### kritik
-  man muss die git-Konfigurationsdatei überprüfen und den url-Link in gitea/gogs SSH-Remote-Repository-Link ändern.
+Das ist ein Beispiel wie ein Lerntagebuch aussehen könnte.
 
-  ### Mitteilung
-  
+## SU 01(21.10.2021)
 
+### Lernziel
 
-  ## Übung 02 (2.11.2022)
-  ### Lernziel
-  - legen Sie in Ihrem Repository die Datei Programmierparadigmen.md an.
-  - Analysieren Sie die Programmiersprachen Java,C,Python,go,JavaScript und TypeScript hinsichtlich der in der Vorlesung genannten Kriterien und Schreiben sie ihre Analyse in Stichpunkten in die neu erstellte datei.
-  - Suchen Sie im Internet nach weiteren Programmierprinzipien und dokumentieren sie diese (Acronym, Langbezeichnung, Beschreibung) in der Obigen Datei.
-  
-  ### Erkenntnis 
-  Ein neu Datei als Programmierparadigmen.md an Gitea hochgeladet.
-
-  ### Kritik 
-  Programmierprinzipien
-    - SOLID
-    - STUPID
-    - KISS (Keep It Simple & Stupid)
-    - FCoH (Favor Composition over Inheritance)
-    - YAGNI (You Ain't Gonna Need It)
-    - IOC (Inversion Of Control)
-    - DI (Dependency Injection)
-    - DRY (Don't Repeat Yourself)
-    - DYC (Document Your Code)
-    - Clean Code at All Cost 
-
-  ### Mitteilung
-
-  ## Übung 3 (16.11.2022)
-
-  clone link https://gogs.informatik.hs-fulda.de/Programmiermethoden_und_werkzeuge-public/UebungDebugging.git 
-
-  ### Lernziel
-  - Führen Sie die Übung entsprechend den Anweisungen in der README.md-Datei aus.
-  - Debugging
+- Organisatorisches
+- Versionskontrollsysteme allgemein
+- git
+- Vorteile
+- wie lege ich ein Repository an
+- vim (ein paar alltägliche Befehle)
+
+### Erkenntnis
+
+Versionskontrolle werden wir im Projekt einsetzen, um
+zu jeder Zeit den Entwicklungsstand einzusehen und paralleles Arbeiten an Dateien zu ermöglichen. Sollten Probleme an der Software auftreten, können wir zu einem funktionierenden Stand wechseln und durch das Commit-Log die Ursache ausfindig machen.
+Außerdem kann ich als Developer mit den gelernten vim-Befehlen vor den anderen flexen.
+
+### Kritik
+
+`git status` zeigt mir einen groben Zustand meines Git-Repositorys an. Manchmal werden Dateien  oder Verzeichnisse dort rot oder grün angezeigt. Die grünen
+Dateien verschwinden von der Ausgabe, wenn ich `git commit`
+ausführe. Rote Dateien werden mit `git add` grün.
+
+### Mitteilung
+
+an die Dozierenden Da dieser Punkt optional ist, lasse ich ihn
+weg. Aber wenn mich irgendwas stört oder begeistert, kann ich es
+hier anmerken.
+
+-----------------------------------
+
+
+## Uebung 01 (27.10.2022)
+
+### Lernziel
+
+- SSH-Zugriff-zum-git-server-konfigurieren
+  - SSH key pair generieren
+  - oeffentlichen SSH key im Repository eintragen
+  - Lokale Kopie auf SSh-Zugriff umstellen
+  - Neue lokale Repositories
   
-  ### Erkenntnis
-  **Task 1 Uebung 1**
-  -  Nachdem Aktivieren Sie die Zeilen 36 bis 38 durch entfernen der beiden *slashes*.
-  **Ausgaben sind:**
-  enter an integer number: 5
-  - input: 5, Schleifenvariable: 2, Ergebnis 1
-  - input: 5, Schleifenvariable: 3, Ergebnis 2
-  - input: 5, Schleifenvariable: 4, Ergebnis 1
-  - number 5 passed check: true% 
+### Erkenntnis
 
-  enter an integer number: 34
-  - input: 34, Schleifenvariable: 2, Ergebnis 0
-  - number 34 passed check: false%
+- einen ssh-key erstellt
+- öffentlichen Schlüssel zu gogs hinzugefügt
+- Master Branch erstellt
 
-  enter an integer number: 89
-  - nachdem schleifen es gibt
-  - number 89 passed check: true%  
+### kritik
 
-  Nachdem einen Breakpoint an ziele 35 und zahl 45 eingeben es gibt 
-  - die Inhalte der Variablen sind nextInt: 45, i:2, ergebnis:1
+man muss die git-Konfigurationsdatei überprüfen und den url-Link in gitea/gogs SSH-Remote-Repository-Link ändern.
 
-  Nochmal lauft das Programm im Debug-modes und eingeben zahl ist 47
-  - die Inhalte der Variablen sind nextInt: 47, i:2, ergebnis:1 dann nextInt: 47, i:3, ergebnis:2
-  - am ende nextInt: 47, i:46 Ergebnis:1 check: true
+### Mitteilung
 
-  **Task 2 Uebung 2**
+---------------------------
 
-  Öffnen Sie das programm `Uebung2.java` im Editor
-  - Starten Sie das Programm mehrfach (*"run as Java Application"*) und geben Sie verschiedenen natürliche Zahlen ein.
+## Übung 02 (2.11.2022)
 
-    - **natürliche zahlen sind 45, 14, 89 ergebnis sind False ingesamt**
+### Lernziel
 
+- legen Sie in Ihrem Repository die Datei Programmierparadigmen.md an.
+- Analysieren Sie die Programmiersprachen Java,C,Python,go,JavaScript und TypeScript hinsichtlich der in der Vorlesung genannten Kriterien und Schreiben sie ihre Analyse in Stichpunkten in die neu erstellte datei.
+- Suchen Sie im Internet nach weiteren Programmierprinzipien und dokumentieren sie diese (Acronym, Langbezeichnung, Beschreibung) in der Obigen Datei.
 
-  - setzen Sie einen BreakPoint in Zeile 40
-  - Starten Sie das Programm wie bisher
-  - Starten Sie das Programm im Debug-Modus und geben Sie die Zahl 45 ein
-  - Notieren Sie die Inhalte der Variablen (this) nextInt: 23 
-    - this: **Uebung2@8**
-    - count: **3**
-  -  Notieren Sie die Anzahl der Einträge in der *Debug View* (this): **this, count, in, out in total 4 mit Zwischenüberschritt**
+### Erkenntnis
 
-  - in welcher Zeile steht der Debugger? 34->36
-  - Notieren Sie die Anzahl der Einträge in der *Debug View* (this)
-    - nextInt: **45**, count: **2**
-  - in welcher Zeile steht der Debugger? **40** 
-  - Notieren Sie die Anzahl der Einträge in der *Debug View* (this) false
-    - nextInt: **16**, count: **4** ergebnis: **false**
+Ein neu Datei als Programmierparadigmen.md an Gitea hochgeladet.
 
-  **Beenden Sie den Debugger (*"Terminate"*)**
+### Kritik
 
-  ### Kritik 
+Programmierprinzipien
 
-  ### Mitteilung
+- SOLID
+- STUPID
+- KISS (Keep It Simple & Stupid)
+- FCoH (Favor Composition over Inheritance)
+- YAGNI (You Ain't Gonna Need It)
+- IOC (Inversion Of Control)
+- DI (Dependency Injection)
+- DRY (Don't Repeat Yourself)
+- DYC (Document Your Code)
+- Clean Code at All Cost
 
+### Mitteilung
 
+----------------------------
 
+## Übung 3 (16.11.2022)
 
+clone link <https://gogs.informatik.hs-fulda.de/Programmiermethoden_und_werkzeuge-public/UebungDebugging.git>
 
+### Lernziel
 
+- Führen Sie die Übung entsprechend den Anweisungen in der README.md-Datei aus.
+- Debugging
 
-  ## Uebung 4 (23.11.2022)
-  ### Lernziel
-  Lokale Respository
-    - Stage und Historic
-    - Merge
-    - rebase
+### Erkenntnis
 
+**Task 1 Uebung 1**
 
+- Nachdem Aktivieren Sie die Zeilen 36 bis 38 durch entfernen der beiden *slashes*.
+**Ausgaben sind:**
+enter an integer number: 5
+- input: 5, Schleifenvariable: 2, Ergebnis 1
+- input: 5, Schleifenvariable: 3, Ergebnis 2
+- input: 5, Schleifenvariable: 4, Ergebnis 1
+- number 5 passed check: true%
 
-  ### Erkenntnis
+enter an integer number: 34
 
-  ### kritik
+- input: 34, Schleifenvariable: 2, Ergebnis 0
+- number 34 passed check: false%
 
-  ### Mitteilung
+enter an integer number: 89
 
+- nachdem schleifen es gibt
+- number 89 passed check: true%  
 
+Nachdem einen Breakpoint an ziele 35 und zahl 45 eingeben es gibt
 
-  ## SU 07 (07.12.2022)
+- die Inhalte der Variablen sind nextInt: 45, i:2, ergebnis:1
 
-  ### Lernziel
-    - Relvante Literatur
-    - Motivation
-    - Grundlagen
-    - Testmethodologie
-    - TestProzess
-    - Psychologische Aspekte  
-  
-  ### Erkenntnis
-  **Testmethodoligie - Bestandteile eine Tests**
+Nochmal lauft das Programm im Debug-modes und eingeben zahl ist 47
+
+- die Inhalte der Variablen sind nextInt: 47, i:2, ergebnis:1 dann nextInt: 47, i:3, ergebnis:2
+- am ende nextInt: 47, i:46 Ergebnis:1 check: true
+
+**Task 2 Uebung 2**
+
+Öffnen Sie das programm `Uebung2.java` im Editor
+
+- Starten Sie das Programm mehrfach (*"run as Java Application"*) und geben Sie verschiedenen natürliche Zahlen ein.
+
+  - **natürliche zahlen sind 45, 14, 89 ergebnis sind False ingesamt**
+
+- setzen Sie einen BreakPoint in Zeile 40
+- Starten Sie das Programm wie bisher
+- Starten Sie das Programm im Debug-Modus und geben Sie die Zahl 45 ein
+- Notieren Sie die Inhalte der Variablen (this) nextInt: 23
+  - this: **Uebung2@8**
+  - count: **3**
+- Notieren Sie die Anzahl der Einträge in der *Debug View* (this): **this, count, in, out in total 4 mit Zwischenüberschritt**
+
+- in welcher Zeile steht der Debugger? 34->36
+- Notieren Sie die Anzahl der Einträge in der *Debug View* (this)
+  - nextInt: **45**, count: **2**
+- in welcher Zeile steht der Debugger? **40**
+- Notieren Sie die Anzahl der Einträge in der *Debug View* (this) false
+  - nextInt: **16**, count: **4** ergebnis: **false**
+
+**Beenden Sie den Debugger (*"Terminate"*)**
+
+### Kritik
+
+### Mitteilung
+
+
+-------------------------------------
+
+## Uebung 4 (23.11.2022)
+
+### Lernziel
+
+Lokale Respository
+
+- Stage und Historic
+- Merge
+- rebase
+
+### Erkenntnis
+
+### kritik
+
+### Mitteilung
+
+-------------------------------------------------
+
+## SU 07 (07.12.2022)
+
+### Lernziel
+
+- Relvante Literatur
+- Motivation
+- Grundlagen
+- Testmethodologie
+- TestProzess
+- Psychologische Aspekte  
+
+### Erkenntnis
+
+**Testmethodoligie - Bestandteile eine Tests**
+
+- Stichprobe
+  - Testfälle
+  - Testdaten
+- Testobekt
+- Testumgebung
+- Testziel
+- Soll-/Ist- Wertvergliech
+
+**Testziele**
+
+- Fehler aufzeigen
+- Qualität erfassen
+- Vertrauen erhöhen
+- Grenzen ermitteln
+
+**Testebenen**
+
+- Anwendung/System
+- Teilsystem/Modul
+- Codeebene/Unit
+
+**Testpyramide**
+
+- GUI Tests (end to end tests)
+business logik überprufen, functions und kommiunikation mit anderen components überprufen.
+- Integration tests
+
+- Component / Contract Tests
+- Unit Tests
+
+**Testnamen**
+
+Test werden benannt nach:
+
+- Ziel (Integration Test, Lasttest)
+- Methode (Regressionstest)
+- Testgegenstand (UI-test, Module-test, Unit-test)
+- Level (Systemtest)
+- Personen (Entwicklertest, Anwendertest)
+- Testabdeckung (Komplettest, partieller Test)
+
+**Qualitätskosten**
 
-  - Stichprobe
-    - Testfälle
+- High Cost -> Poor Quality -> Failure Costs
+- High Cost ->  Exceptional Quality -> Sweet Spot (prevention & Appraisal Cost)
+- Low Cost -> Exceptional Quality -> prevention & Appraisal Cost
+
+**Testprozess**
+
+**Testprozess - Ablauf**
+
+**Testprozess - Plannung**
+
+**Testprozess - Analyse & design**
+
+- basiert auf Anforderungsdokumentation
+- Testspezifikation
+  - Testfaelle
+    - Kritikalitaet
     - Testdaten
-  - Testobekt
-  - Testumgebung
-  - Testziel
-  - Soll-/Ist- Wertvergliech
+    - Testumgebung
+  - Ausfuehrungsreihenfolge
+  - Infrastruktur
+  - Testkriterium
+
+**Testprozess - Testausfuerung**
+
+Testlog
+
+- aufgetretenes Fehlverhalten
+- Fehlerkategorie (high/medium/low)
+
+**Testprozess - Testnachbereitung**
+
+- Testreport
+- Zusammenfassung Testausfuehrungen
+- Vergleich mit frueheren Testlaeufen
+- Entscheidung ueber Lieferfaehigkeit
+  
+### kritik
+
+### Mitteilung
+
+----------------------------------------
+
+## SU (14.12.2022)
+
+### Lernziel
+
+- Automatisiertes Testen von Software
+  - Motivation
+  - Grundlegen
+  - UnitTests
+  - Anforderungen an zu testenden Code
+
+### Erkenntnis
+
+**Motivation** - *warum automatiestert Testen?*
+Probleme manuellen Testens
+
+- Testfähigkeit der Software
+- Wiederholbarkeit
+  - nachlassende Aufmerksamkeit
+  - unterschiedlicher Kontetn verschiedener Tester:Innen
+  - Überlappungen / Lücken bei der Testausführung
+- Fehlerzustände Testen
+- Wissen der Tester:Innen
+  - unvollständige Testdokumentation, setzt implizites Wissen voraus
+  - Bedienung der Anwendung
+  - Bedienung der Testwerkzeuge
+- Aufwand
+  - langsam
+  - Arbeitszeit
+
+**Motivation** - *Qualitätskosten*
+
+**Motivation** - *Gründe gegen Automatisiert Tests*
+
+Wie kann ich das testen?
+
+- nur User interface
+- prettier Code
+- Keine Tests
+Persönliche, technische und Soziale Voraussetzungen
+- UnitTests schreiben ist eine Fertigkeit und muss ständig geübt werden.
+- Technische Voraussetzungen müssen sichergestellt sein.
+- Team und Vorgesetzte müssen automatisiertes Testen unterstützen.
+
+Für jedes Verhalten, das wir bei einer Person beobachten ist deren Umfeld perfekt daraus ausgereichtet, dieses Verhalten zu fördern.
+
+--------------------------
+
+**Grundlagen** - *Wleche Tests automatisierien?*
 
-  **Testziele**
+- häufige Wiederholung
+- hohe Anzahl
+- hohe Kritikatiltät
+- hohe Stabilität
+- Unittests
+- Modultests
+  - Integrationstest
+  - Regressionstest
+- ApplicationTests
+  - Integrationstest
+  - Regressionstest
+  - Lasttests
+  - Acceptance-Tests
 
-  - Fehler aufzeigen
-  - Qualität erfassen
-  - Vertrauen erhöhen
-  - Grenzen ermitteln
+**Unterschied Application / Module-Tests zu UnitTests**
+*Appplication und Module*
 
-  **Testebenen**
+- werden spät im entwicklungsprozess ausgeführt
+- Testwerkzeuge sind Komplex
+- sind aufwendig zu warten
+- zeigen, das ein Fehler existiert
 
-  - Anwendung/System
-  - Teilsystem/Modul
-  - Codeebene/Unit
+*UnitTest*
 
-  **Testpyramide**
+- laufen früh im Entwikclungsprozess (idealer Weise nach jedem Spiechern)
+- Werkzeuge haben einfache API
+- sind stabil gegen Änderungen(anderer Units)
+- zeigen welche Anforderung nicht erfüllt wird, wo der Fahler existiert und unter welchen Bedigungen er auftritt.
 
-  - GUI Tests (end to end tests)
-  business logik überprufen, functions und kommiunikation mit anderen components überprufen.
-  - Integration tests
+--------------------------
 
-  - Component / Contract Tests
-  - Unit Tests
+***UnitTests***
 
-  **Testnamen**
+Was macht ein Unittest?
 
-  Test werden benannt nach:
-  - Ziel (Integration Test, Lasttest)
-  - Methode (Regressionstest)
-  - Testgegenstand (UI-test, Module-test, Unit-test)
-  - Level (Systemtest)
-  - Personen (Entwicklertest, Anwendertest)
-  - Testabdeckung (Komplettest, partieller Test)
+- Unittests sind ausführbare Dokumentation.
+- Unittest testen keinen Code.
+- Unittest verifizieren von außen beobachtbares gewünschtes Verhalten von Code.
+Sie prüfne Rüchgabewerte und kommuikation mit anderen Units des zu testenden Codes als Reacktion auf die übergebenen Parameter und/oder den Reaktionen der anderen Units.
+- Ein einzelner Test prüft genau eine Erwartung an die Unit.
+- Unittests verhindern ungewollte Änderungen.
+  
+
+***Wie schreibt man einen guten Unittest?***
+
+**F**ast - schnell
+Kann nach jedem speichern ausgeführt werden ohne den Arbeitsablauf zu verzögern.
+
+- primitive Vorbereitung (setup)
+- Abhängigkeiten durch Test-Doubles ersetzen
+
+**I**ndependent - unabhängig
+Jeder Test kann einzeln ausgeführt werden.
+
+- kein Test schafft Voraussetzungen für nachfolgende
+- Test können in beliebiger Reihenfolge laufen
+
+**R**epeatable - wiederholbar
+Jede Ausführung (ohne Änderung des getesteten Codes) führt zum selben
+Ergebnis.
+
+- nicht von zufälligen Größen abhängig
+- kein Einfluß durch Änderungen an anderen Units
+- kein Einfluß durch Testumgebung (Netzwerk, Festplatte, Position in der Verzeichnisstruktur)
+
+**S**elfevaluating - selbstauswertend
+Das Testergebnis ist eindeutig und binär.
+
+- Erfolg oder Mißerfolg sind eindeutig erkennbar
+- Ergebnis muss nicht in Logdateien o.ä. gesucht werden
+- Ergebnis kann automatisiert weiter verarbeitet werden
+
+**T**imely - zeitnah
+Unittests entstehen zeitnah zum getesteten Code.
+
+- Code first
+Tests werden nach dem zu testenden Code geschrieben.
+- Test first
+Tests werden vor dem zu testenden Code geschrieben.
+- Test Driven Developement
+Test und verifizierter Code entstehen gleichzeitig
+
+**R**eadable - was bedeutet *lesbar*?
 
-  **Qualitätskosten**
+- was wird getestet
+  Name des Test drückt Vorbedingungen und erwartetes Ergebnis aus.
+- Kurz
+  wiederkehrende Vorbereitungen im Methoden auslagern
+- Welche Eigenschaften der Parameter sind wichtig?
+  Explizit Variablen für Parameterwerte anlegen
+  Variablennamen sorgsam wählen
+- Welche Eigenschaften der Ergebnisse sind wichtig?
+  Explizit Variablen für Ergebnisse anlegen
+  Variablennamen sorgsam wählen
+  verifizierungsmethoden mit sprechenden Namen.
 
-  - High Cost -> Poor Quality -> Failure Costs
-  - High Cost ->  Exceptional Quality -> Sweet Spot (prevention & Appraisal Cost)
-  - Low Cost -> Exceptional Quality -> prevention & Appraisal Cost
+**T**rustworthy  - Was bedeutet vertrauenswürdig?
 
+- Geschäftsanforderungen erfüllt
+  Wurde tatsächlich implementiert, was der Kunde wollte?
+- technisch
+  Wird der Produktivcode tatsächlich ausgefühtrt?
+  - "test first"
+  Schlägt der Test aus dem richtigen Grund fehl?
+  - Ersetzten von Abhängigkeiten(Mocking)
+  - (weitestgehend) keine Logik in Tests 
 
-  **Testprozess**
+**F**ast
+(schone erklärt)
 
-  **Testprozess - Ablauf**
+**M**aintainable - Was bedeutet wartbar?
 
+- Stabilität gegenüber Anderungen in anderen Units
+Abhängigkeiten ersetzen
+- stabil gegen Änderungen in der Unit selbst
+eine einzelne Anforderung (nicht Codestelle) testen.
 
-  **Testprozess - Plannung**
+----------------------------
 
-  **Testprozess - Analyse & design**
+***Anforderungen an zu testenden Code***
 
-  - basiert auf Anforderungsdokumentation
-  - Testspezifikation
-    - Testfaelle
-      - Kritikalitaet
-      - Testdaten
-      - Testumgebung
-    - Ausfuehrungsreihenfolge
-    - Infrastruktur
-    - Testkriterium
+- Was verbessert die Testbarkeit?
+- Isolieren einer Unit
+- Isolation Ermöglichen
 
-  **Testprozess - Testausfuerung**
+----------
+
+*Testbarkeit von production Code*
+
+Qualität des producktivem code (im Sinne von "Clean Code" und dem "S.O.L.I.D" prinzip) beeinflußt die Qualität der Tests (im Sinne der RTFM - Anforderungen)
+
+die wichtigsten "Clean Code" Regeln sind:
+
+- Separation of Concerns / single responsibility
+  Erzeugung von Objekten der Abhängigkeiten ist keine aufgabe der Geschäftslogik!
+- Dependency Inversion
+- Tell! Don´t ask.
+- Law of Demeter (Don´t talk to strangers)
+  vermeide "message chaining" (nicht mit "fluent API" verwechseln)
+
+*Arten von Test-Doubles*
+
+- Stub
+  - leere Implementierung einen Schnittstelle, üblicher Weise generiert
+- Fake
+  - alternative Implementierung einer Schnittstelle oder Erweiterung einer existerenden Implementierung.
+  - exterm vereinfachtes Verhalten(keine Logik)
+- Mock
+  - "aufgemotztes" Fake
+  - konfigurierbares Verhalten
+  - Verifizierung vom Methodenaufrufen und der übergebenen Parameter
   
-  Testlog
-  - aufgetretenes Fehlverhalten
-  - Fehlerkategorie (high/medium/low)
-
-  **Testprozess - Testnachbereitung**
- 
-  - Testreport
-  - Zusammenfassung Testausfuehrungen
-  - Vergleich mit frueheren Testlaeufen
-  - Entscheidung ueber Lieferfaehigkeit
-    
-  ### kritik
-
-  ### Mitteilung
+*Was Ermöglicht die Ersetzung von Abhängigkeiten?*
+
+- trenne Instanyiierung der Abhängigkeiten von der Geschäftslogik
+- vermeide den Aufruf des ***new*** Operators
+- Bereitstellen von "seams" (Nahtstellen)
+  - dependencz injection
+  - Getter mit geringer Sichtbarkeit
+- keine **static** (public) Methoden
+- keine **final** (public) Methoden
+- vermeide *Singelton Pattern* (nicht Singelton als Konzept)
+
+
+*Schreibe "Clean Code"*
+
+- programmiere gegen Schnittstellen
+- SoC/ SRP (Feature envy)
+- Law of Demeter
+- DRY
+- same level of abstraction
+  
+
+### kritik
+
+### Mitteilung