update

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

@@ -457,3 +457,66 @@
     - Falls einer nicht funktioniert geht der andere nicht
   - Ausnahme:
     - out-of-process-Abhängigkeit, die nur schwer in den gewünschten Zustand kommt
+
+## Test Coverage
+> Test-Abdeckung wird häufig genutzt, um die Qualität einer Test-Suite zu beurteilen
+
+> Niedrige Coverage zeigt, dass die Test-Suite nicht ausreichend ist.
+>
+> Hohe Coverage bedeutet nicht, dass die Test-Suite gut ist
+
+### Code Coverage
+- Anteil der Code-Zeilen, die durch die Tests ausgeführt werden 
+- Beispiel:
+  - ![image_657.png](image_657.png)
+    - 80% Coverage
+  - ![image_658.png](image_658.png)
+    - 100% Coverage
+    - nicht besser als der Test oben, der True outcome wird ja trotzdem nicht überprüft
+
+### Branch Coverage
+- Anteil der Code-Branches die durch die Tests ausgeführt werden
+- Beispiel: 
+  - ![image_659.png](image_659.png)
+  - 1 / 2 Branches gecovered → 50% Coverage
+- **Gibt meist wertvollere Ergebnisse als Code-Coverage**
+
+### Probleme mit Coverage-Metriken
+- Keine Garantie, dass der Test alle möglichen Ausgänge überprüft
+  - um die Garantie zu haben:
+    - Alle Codepfäde müssen getestet werden
+    - Asserts müssen da sein 
+      - ![image_660.png](image_660.png)
+      - führt zwar alles aus, überprüft aber nicht ob es richtig ist, weil nix asseert 
+    - ein System kann teilweise mehrere Outcomes haben
+      - Alle müssen getestet werden
+- Keine Coverage-Metrik kann Code in externen Libraries abbilden
+- Externe Bibliotheken
+  - ![image_661.png](image_661.png)
+  - Test-Coverage ist bei 100%
+  - Es sind aber trotzdem nicht alle möglichen Outcomes abgedeckt
+    - bspw. wenn die Zahl zu groß ist, keine da ist, ...
+- **Coverage-Metriken sind nur Indikatoren, nix tatsächlich final festlegendes**
+
+## Rubber Duck Debugging
+> Wenn verzweifelt → Den Fehler einer Gummiente erklären
+
+- Wenn man versucht jemandem das Problem zu erklären ist man gezwingen
+  - Das Problem von einer anderen Perspektive anzusehen
+  - Dadurch ein tieferes Verständnis vom Problem zu bekommen
+  - einfacher eine Lösung zu finden
+
+![image_662.png](image_662.png)
+
+
+## Pair Programming
+- Zu zweit auf einer Maschine Code schreiben
+  - gleichzeitig auch Arbeit planen und diskutieren
+- Idee dahinter:
+  - zwei Gehirne und vier Augen sind besser als ein Gehirn und 2 Augen
+- Teams haben ausprobiert und festgestellt
+  - geht schneller, da man fokussierter bleibt
+  - höhere Code-Qualität
+
+### Pairing Styles
+-