update

Writerside/topics/04/Rechnernetze/00_RNIntroduction.md

@@ -160,3 +160,6 @@
 - Kombination von IP-Adresse und Port
 
 ![image_578.png](image_578.png)
+
+
+weiter gehts bei https://lernen.h-da.de/pluginfile.php/1074664/mod_resource/content/1/S01_Motivation_und_Einleitung_2024-04-16.pdf Seite 47

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

@@ -55,7 +55,142 @@
 
 ## Goals of Testing during Implementation
 ### Aktiviere nachhaltiges Wachstum des Software-Projekts
+- ![image_579.png](image_579.png)
 - Nachhaltigkeit ist wichtig
   - Projektwachstum ist am Anfang einfach
   - Das Wachstum zu halten ist schwer
-- 
+- Tests können das nachhaltige Wachstum fördern
+  - Aber: erfordern initialen, teilweise signifikanten Einsatz
+- Schlechte Tests bringen nichts
+  - verlangsamen am Anfang schlechten Code
+  - langfristig trotzdem ungünstig
+- Test Code ist Teil der Codebase
+  - Teil, der ein spezifisches Problem behandelt - Anwendungsrichtigkeit sicherstellen
+- Kosten eines Tests
+  - Wert
+  - anstehende Kosten
+    - _Refactoring des Tests, wenn der Code refactored wird_
+    - _Test bei jeder Codeänderung ausführen_
+    - _Mit Fehlalarmen durch den Test umgehen_
+    - _Zeit für das Verstehen des Tests, wenn man den zu testenden Code verstehen möchte_
+
+### General Testing Strategy
+#### Testing Automation Pyramid
+![image_580.png](image_580.png)
+- Software Tests in 3 Kategorien aufteilen
+  - **UI-Tests**
+    - Testen die Anwendung durch Interaktion mit der UI
+    - sehr high-level
+  - **Service Tests**
+    - [Black-Box](#black-box-testing) testen von größeren Softwareteilen
+      - _bspw. Komponenten, Services_
+  - **Unit Tests**
+    - werden während Entwicklung von Developern geschrieben
+- Gibt Idee, wie viele Tests pro Kategorie in der Test-Suite sein sollten
+
+#### Testing Ice Cream Cone
+![image_581.png](image_581.png)
+- Style einer Test-Suite, die häufig in der Industrie verwendet wird
+  - hohe Anzahl manueller, high-level Tests
+  - end-to-end Tests (auch an UI), die automatisch ausgeführt werden können
+  - nur wenige integration/unit tests
+- Tests Suite mit dieser Strategie ist nicht gut wartbar
+  - manuelle Tests sind teuer und langwierig
+  - automatisierte high-level Tests gehen häufig kaputt, sobald Änderungen in der Anwendung auftreten
+
+
+
+### Test Driven Development (TDD)
+![image_582.png](image_582.png)
+1. Tests schreiben
+   - **Design**
+     - Akzeptanzkriterien für den nächsten Arbeitsschritt festlegen
+     - Anregung [lose gekoppelte Komponenten](ImplementingForMaintainability.md#loose-coupling) zu entwerfen
+       - einfache Testbarkeit, dann verbinden
+     - Ausführbare Beschreibung von dem was der Code tut
+   - **Implementierung**
+     - Vervollständigen einer regressiven Test-Suite
+2. Tests ausführen
+   - **Implementierung**
+     - Error erkennen, während der Kontext noch frisch ist
+   - **Design**
+     - Bewusstmachung, wann die Implementierung vollständig ist
+
+> Golden Rule of TDD: schreibe niemals neue Funktionalitäten ohne einen fehlschlagenden Test
+
+#### Vorteile des TDD
+- signifikante Reduktion der Defekt-Rate
+  - auf Kosten eines moderaten Anstiegs im initialen Development-Prozesses
+- Empirische Untersuchungen haben das noch nicht bestätigt
+  - TDD hat aber zu Qualitätssteigerung des Codes geführt
+
+#### Häufige Fehler beim TDD
+- Individuelle Fehler
+  - _Vergessen die Tests regelmäßig auszuführen_
+  - _Zu viele Tests auf einmal schreiben_
+  - _Zu große/grobe Tests schreiben_
+  - _zu triviale Tests schreiben, die eh funktionieren_
+- Team-Fehler
+  - _Nur partieller Einsatz_
+  - _Schlechte Wartung der Test-Suite_
+  - _Verlassene Test-Suite (nie ausgeführt)_
+
+## Unit-Testing vs. Integration Testing
+| Unit                          | Integration          |
+|-------------------------------|----------------------|
+| kleiner Teil eines Verhaltens | größere Portion Code |
+
+![image_583.png](image_583.png)
+
+### 4 Typen von Produktions-Code
+![image_584.png](image_584.png)
+
+#### Dimensionen
+##### Komplexität und Domain-Signifikanz
+- Code Komplexität
+  - Definiert durch Nummer der Branching-Punkte im Code
+  - _if-statements, Polymorphismus_
+- Domain-Signifikanz
+  - Wie signifikant ist der Code für die problematische Domain
+  - normalerweise Verbindung Domain-Layer-Code zu End-User-Ziele
+    - Hohe Domain-Signifikanz
+  - _Bsp. für niedrige Relevanz: Utility Code_
+
+##### Nummer der Kollaborateure
+- Kollaborateur = Abhängigkeit, die veränderlich /& außerhalb des Prozesses ist
+  - veränderlich
+    - nicht nur read-only
+  - außerhalb des Prozesses
+    - häufig geteilt
+    - hindert Tests an unabhängiger Ausführung
+- Code mit vielen Kollaborateuren ist schwer zu testen
+
+
+#### Typen
+##### Domain model & algorithms
+- **Domain Code, wenige Kollaborateure**
+- komplexer Code häufig Teil des Domain-Models
+- wenige Kollaborateure → Testbarkeit
+- sollte NIEMALS Abhängigkeiten außerhalb des Prozesses haben
+##### Controllers
+- **Wenig Domain Code, viele Kollaborateure**
+- Koordination der Ausführung von Use-Cases für Domain-Klassen und externen Anwendungen
+- Keine komplexe / Business-kritische Arbeit selbst/allein machen
+- wenig Komplexität, wenig Domain-Signifikanz
+- Viele Abhängigkeiten außerhalb des Projekts
+##### Overcomplicated Code
+- **Viel Domain Code, viele Kollaborateure**
+- ist aber auch komplex und wichtig
+##### Trivialer Code
+- **wenig Domain-Code, wenig Kollaborateure**
+
+#### Separierung von Controllers & DomainModel, Algorithmen
+![image_585.png](image_585.png)
+- Separiert komplexen Code von Code, der Orchestrierung macht
+  - Domain Code hat tiefe Implementierung in Business Logik
+  - Controller haben breite Orchestrierung aber enge Komplexität
+- Erhöht Wartbarkeit und Testbarkeit
+
+#### Wie testet man die 4 Typen?
+![image_587.png](image_587.png)
+- trivialer Code muss nicht getestet werden