update

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

@@ -194,6 +194,7 @@
 ![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 
@@ -374,3 +375,85 @@
     - je mehr Parameter, desto schwieriger
 
 
+## Integration Testing
+- Verifiziert größeren Teil des Systems (mehrere Units)
+  - aus dem [Controllers-Quadranten](#4-typen-von-produktions-code)
+- braucht evtl. länger als ein Unit-Test
+- ist evtl. abhängig von anderen Tests (keine Isolation)
+
+- Balance zwischen Unit- und Integration-Tests ist wichtig
+  - direktes Arbeiten mit out-of-process-Abhängigkeiten macht Integration Tests langsam
+    - sind teuer zu warten
+    - dafür besserer Schutz gegen Zurückentwicklungen
+  - Integration-Tests für den längsten Happy-Path mit den meisten Abhängigkeiten
+  - Eck-Szenarien des Business-Szenarios mit Unit-Tests
+
+- Out-of-Process Abhängigkeiten
+  - **Managed** (_Abhängigkeiten über die wir volle Kontrolle haben_)
+    - nur Zugriff über die Applikation
+    - Interaktionen sind für die externe Welt nicht sichtbar
+    - **nicht mocken**
+      - wir wollen, dass die tests fehlschlagen, wenn wir was an der DB ändern bspw.
+  - **Unmanaged** (_Abhängigkeiten über die wir keine Kontrolle haben_)
+    - **mocken**
+      - wir wollen volle Kontrolle über die Tests
+
+### Integration Testing - Example
+**Customer Management System**
+![image_611.png](image_611.png)
+- alle User sind in einer DB
+- Änderungen werden an angeschlossene Anwendungen über Message-Bus geschickt
+- Business-Rules
+  - Falls Email zur Company-Domain gehört → Employer Status, sonst Customer
+  - System muss Anzahl der Employer tracken (auch beim Wechseln)
+  - Wenn Mail wechselt müssen externe Systeme über MessageBus benachrichtigt werden
+
+![image_612.png](image_612.png)
+
+- **Domain model, Algorithms**
+  - Company
+    - Attribute: `DomainName` `NumberOfEpmoyees`
+    - Methoden: `ChangeNumberOfEmployees(...)` `IsEmailCorporate(...)`
+  - CompanyFactory
+    - Erstellt `Company`-Objekte anhand von DB-Feldern
+  - User
+    - Attribute: `UserId` `Email` `UserType` `EmailChangedEvents[]`
+    - Methoden: `ChangeEmail(...)`
+  - UserFactory
+    - Erstellt `User`-Objekte anhand von DB-Feldern
+- **Controllers**
+  - UserController
+    - Delegiert die Ausführung von Email-Änderungen
+    - Logik ist gekapselt in den Domain-Klassen
+    - Managed Kommunikation mit out-of-process-Abhängigkeiten
+      - hier: DB und messageBus
+
+- **Integration Test für den längsten Happy-Path**
+  - geht durch alle Abhängigkeiten
+    - _hier: corporate → non-corporate Mail_
+  - davor: out-of-process-Abhängigkeiten Kategorisieren
+    - was direkt testen, was mocken?
+      - _hier: DB ist managed → direkt testen_
+      - _hier: messageBus ist unmanaged → mocken_
+        - _[OCP](DesignPrinciples.md#o-open-closed-principle-ocp) anwenden durch ein Interface_
+      - ![image_614.png](image_614.png)
+- **Edge-cases mit Unit-Tests**
+
+![image_613.png](image_613.png)
+
+### Integration Testing - Good Practices
+- Immer einen festen Platz für das [Domain-Model](#domain-model-algorithms) in der Code-Base haben
+  - unit-tests dafür, integration-tests für Controller
+  - Abgrenzung kann unterschiedlich vorgenommen werden
+    - package, namespace, assembly, ...
+- Möglichst wenig Layer in der Anwendung
+  - Abstraktionen und Generalisierungen → mehr Layer
+    - wird schwer den Code nachzuvollziehen
+    - ![image_615.png](image_615.png)
+  - ![image_616.png](image_616.png)
+- Dopplungen im [AAA](#aaa-sequenz)-Schema
+  - teilweise verlockend
+    - ![image_617.png](image_617.png)
+    - Falls einer nicht funktioniert geht der andere nicht
+  - Ausnahme:
+    - out-of-process-Abhängigkeit, die nur schwer in den gewünschten Zustand kommt