diff --git a/Writerside/images/image_591.png b/Writerside/images/image_591.png new file mode 100644 index 0000000..b77eb6f Binary files /dev/null and b/Writerside/images/image_591.png differ diff --git a/Writerside/images/image_592.png b/Writerside/images/image_592.png new file mode 100644 index 0000000..3a59f5c Binary files /dev/null and b/Writerside/images/image_592.png differ diff --git a/Writerside/images/image_593.png b/Writerside/images/image_593.png new file mode 100644 index 0000000..8105dfd Binary files /dev/null and b/Writerside/images/image_593.png differ diff --git a/Writerside/images/image_594.png b/Writerside/images/image_594.png new file mode 100644 index 0000000..3ea9871 Binary files /dev/null and b/Writerside/images/image_594.png differ diff --git a/Writerside/images/image_595.png b/Writerside/images/image_595.png new file mode 100644 index 0000000..af55a29 Binary files /dev/null and b/Writerside/images/image_595.png differ diff --git a/Writerside/images/image_596.png b/Writerside/images/image_596.png new file mode 100644 index 0000000..53cdcad Binary files /dev/null and b/Writerside/images/image_596.png differ diff --git a/Writerside/images/image_597.png b/Writerside/images/image_597.png new file mode 100644 index 0000000..6d899e8 Binary files /dev/null and b/Writerside/images/image_597.png differ diff --git a/Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md b/Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md index 098235e..e05eb0b 100644 --- a/Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md +++ b/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:** + - \ No newline at end of file