diff --git a/Writerside/images/image_579.png b/Writerside/images/image_579.png new file mode 100644 index 0000000..6f00e28 Binary files /dev/null and b/Writerside/images/image_579.png differ diff --git a/Writerside/images/image_580.png b/Writerside/images/image_580.png new file mode 100644 index 0000000..4afee17 Binary files /dev/null and b/Writerside/images/image_580.png differ diff --git a/Writerside/images/image_581.png b/Writerside/images/image_581.png new file mode 100644 index 0000000..6f2f035 Binary files /dev/null and b/Writerside/images/image_581.png differ diff --git a/Writerside/images/image_582.png b/Writerside/images/image_582.png new file mode 100644 index 0000000..e52ff75 Binary files /dev/null and b/Writerside/images/image_582.png differ diff --git a/Writerside/images/image_583.png b/Writerside/images/image_583.png new file mode 100644 index 0000000..956cc9b Binary files /dev/null and b/Writerside/images/image_583.png differ diff --git a/Writerside/images/image_584.png b/Writerside/images/image_584.png new file mode 100644 index 0000000..75b9f80 Binary files /dev/null and b/Writerside/images/image_584.png differ diff --git a/Writerside/images/image_585.png b/Writerside/images/image_585.png new file mode 100644 index 0000000..3bde051 Binary files /dev/null and b/Writerside/images/image_585.png differ diff --git a/Writerside/images/image_586.png b/Writerside/images/image_586.png new file mode 100644 index 0000000..58c9361 Binary files /dev/null and b/Writerside/images/image_586.png differ diff --git a/Writerside/images/image_587.png b/Writerside/images/image_587.png new file mode 100644 index 0000000..905a9c9 Binary files /dev/null and b/Writerside/images/image_587.png differ diff --git a/Writerside/topics/04/Rechnernetze/00_RNIntroduction.md b/Writerside/topics/04/Rechnernetze/00_RNIntroduction.md index def62f3..22c205e 100644 --- a/Writerside/topics/04/Rechnernetze/00_RNIntroduction.md +++ b/Writerside/topics/04/Rechnernetze/00_RNIntroduction.md @@ -159,4 +159,7 @@ - Implementierung als Teil des Kernels oder als separate Bibliothek - Kombination von IP-Adresse und Port -![image_578.png](image_578.png) \ No newline at end of file +![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 diff --git a/Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md b/Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md index 3319604..098235e 100644 --- a/Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md +++ b/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 -- \ No newline at end of file +- 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