update

Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md

@@ -42,15 +42,14 @@
 - Developer Tests:
   - Unit tests
     - Verifizieren Funktionalität eines kleinen Subsets des Systems
+    - Unit Tests sind die essenzielle Basis einer guten Test-Suite
+      - Verglichen mit anderen, sind sie einfach zu erstellen und warten
+      - Viele Unit-Tests :) 
   - Component-/Integration Tests:
     - Verifizieren Verhalten eines größeren Teils
 
 - Tests sind nicht für den Kunden
 
-## Unit Testing
-- Unit Tests sind die essenzielle Basis einer guten Test-Suite
-  - Verglichen mit anderen, sind sie einfach zu erstellen und warten
-  - Viele Unit-Tests :)
 
 
 ## Goals of Testing during Implementation
@@ -194,3 +193,118 @@
 #### Wie testet man die 4 Typen?
 ![image_587.png](image_587.png)
 - trivialer Code muss nicht getestet werden
+
+## Unit Testing
+- Beim Unit Testing gehts nicht nur um den technischen Aspekt
+  - möglichst wenig Zeit Input 
+  - möglichst viel Benefits 
+
+### Gute Test-Suite
+1. integriert in [SDLC](00_Introduction.md#software-development-lifecycle-sdlc)
+   - Tests bringen nur was, wenn man sie ständig benutzt
+     - am besten alle automatisiert bei jeder Änderung
+2. testet nur die wichtigsten Teile der Code-Base
+   - Business-Logik 
+   - Systemkritische Teile
+     - auch Abhängigkeiten nach außen
+   - Rest nur indirekt / wenig testen
+3. gibt maximalen Wert mit minimalem Wartungsaufwand
+   - Auch automatisierte Tests müssen ggf. nach Änderungen angepasst werden
+     - Nur Tests behalten, die wirklich sinnvoll sind
+
+### Was ist ein Unit-Test
+> 1. Verifiziert einen kleinen Teil des Codes (unit)
+> 
+> 2. macht es schnell
+> 
+> 3. macht es isoliert
+
+#### London School Interpretation
+- Isolation bedeutet, dass jede Klasse ihren eigenen Test bekommt
+  - Auch wenn sie von gleicher Klasse erben
+
+##### Testing Doubles
+![image_591.png](image_591.png)
+- Objekt, dass gleiches Verhalten und Aussehen, wie Gegenstück hat
+- Vereinfachte Version, die Komplexität verringert
+
+##### Vorteile London School Interpretation
+- Wenn ein Test fehlschlägt, ist klar, was kaputt ist
+- Gibt Fähigkeit den Objektgraphen aufzusplitten
+  - Jede Klasse hat ihre eigenen Abhängigkeiten / Vererbungen
+  - Schwer zu testen ohne [Testing Doubles](#testing-doubles)
+  - Es müssen nicht die Abhängigkeiten von Abhängigkeiten beachtet werden
+    - haben ja eigene Tests
+- Projektweite Guideline:
+  - Nur eine Klasse auf einmal
+  - ![image_592.png](image_592.png)
+
+
+#### Classic School Interpretation
+- Isolation bedeutet, dass jeder Test in Isolation läuft
+  - Mehrere Klassen auf einmal ist okay
+    - Solange sie alle auf ihrem eigenen Speicher laufen
+    - kein geteilter Zustand
+  - Verhindert Kommunikation /Beeinflussung zwischen Tests 
+    - Scheiß auf Reihenfolge oder Ergebnis von anderen Tests
+##### Geteilte, private, Out-Of-Process Abhängigkeiten
+- Geteilte Abhängigkeiten
+  - Können sich gegenseitig beeinflussen
+    - Müssen ersetzt werden
+    - _bspw. geteilte DB → neue/bearbeitete Daten können Tests beeinflussen_
+- Private Abhängigkeiten → :)
+- Out-Of-Process Abhängigkeiten
+  - Meistens ähnlich wie geteilte Abh.
+    - _DB = geteilt und out-of-process_
+  - _read-only-DB ist fine_
+  - also: kommt drauf an ob gut oder nicht
+![image_593.png](image_593.png)
+
+#### Beispiel Classic School
+![image_594.png](image_594.png)
+- _Enough inventory → purchase geht durch, inventory amount geht runter_
+- _not enough product → kein purchase, keine änderungen_
+
+- Typische AAA-Sequenz
+  - arrange, act, assert
+    - alle Abhängigkeiten und System vorbereiten
+    - Verhalten ausführen, das verifiziert werden soll
+    - Erwartete Ergebnisse überprüfen
+
+- Outcome:
+  - `Customer` und `Store` werden verifiziert, nicht nur `Store`
+  - Jeder Bug in `Store` lässt die Tests fehlschlagen
+    - auch wenn `Customer` komplett richtig ist
+
+#### Beispiel London School
+![image_595.png](image_595.png)
+
+- Gleiche Tests, aber Store wird mit test-doubles ersetzt
+  - "fake dependency" = "Mock"
+
+- AAA Sequenz
+  - Arrange:
+    - Store nicht modifizieren, stattdessen festlegen, wie er auf `hasEnoughInventory()` reagieren soll
+  - Act
+  - Assert
+    - Interaktion zwischen `Store` und `Customer` wird genauer untersucht
+
+#### Vergleich Classic / London
+|                | Isolation of | A unit is                   | Uses test doubles for          |
+|----------------|--------------|-----------------------------|--------------------------------|
+| London School  | Units        | A class                     | All but immutable dependencies |
+| Classic School | Unit tests   | A class or a set of classes | shared dependencies            |
+
+![image_596.png](image_596.png)
+
+### Unit Tests - Good Practices
+#### Good Practices - Structuring
+![image_597.png](image_597.png)
+- Offensichtliche Struktur ist wichtig
+  - Code wird häufiger gelesen als geschrieben
+- AAA-Pattern splittet Tests in 3 Teile
+  - Alternative: Give-When-Then Pattern
+    - Einziger Unterschied: besser lesbar für nicht-Programmierer
+  
+- **Zu vermeidende Dinge:**
+  -