update

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

@@ -235,7 +235,8 @@
 ## Klassifikation von Netzwerken
 ### Nach Entfernung / Distanz
 ![image_607.png](image_607.png)
-![image_608.png](image_608.png)
+> Schadet nicht je ein Beispiel zu kennen, evtl. Klausur
+> ![image_608.png](image_608.png)
 
 ### Leitungs- / Paketvermittelt
 - Leitungsvermittelt

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

@@ -282,7 +282,7 @@
 - Gleiche Tests, aber Store wird mit test-doubles ersetzt
   - "fake dependency" = "Mock"
 
-- AAA Sequenz
+- AAA Sequenz {id="aaa-sequenz"}
   - Arrange:
     - Store nicht modifizieren, stattdessen festlegen, wie er auf `hasEnoughInventory()` reagieren soll
   - Act
@@ -306,5 +306,71 @@
   - Alternative: Give-When-Then Pattern
     - Einziger Unterschied: besser lesbar für nicht-Programmierer
   
-- **Zu vermeidende Dinge:**
-  - 
+##### Zu vermeidende Dinge
+  - Manchmal benutzt ein Test **mehrere AAA Steps**
+    - bspw: ![image_609.png](image_609.png)
+    - ist kein Unit-Test mehr, sondern ein [Integration-Test](#unit-testing-vs-integration-testing)
+  - **if-statements**
+    - wird schwerer lesbar
+    - sollte eine simple Sequenz ohne branches sein
+
+##### Größe der [AAA](#aaa-sequenz) Sections
+- **arrange** 
+  - meistens am größten
+  - falls deutlich größer als act und assert zusammen
+    - extrahieren in neue Methode oder separate [Factory-Klasse](DesignPatterns.md#factory-method-virtual-constructor)
+- **act**
+  - sollte nicht mehr als eine Zeile sein
+- **assert**
+  - kann mehrere Asserts beinhalten
+    - eine unit kann ja auch mehrere Dinge verändern, die überprüft werden müssen
+  - zu viele asserts implizieren schlechten Production-Code
+    - _fehlende Abstraktion bspw._
+- **teardown-Phase** (_alles wieder auf den alten Stand bringen_)
+  - die meisten unit-Tests brauchen keine
+  - ist meistens durch ein anderes Modell gelöst
+    - bspw. Mocks oder so 
+
+#### Good Practices - Naming Tests
+- aussagekräftige Namen
+- häufig aber schlecht:
+  - [MethodeDieGetestetWird]_[Szenario]_[ErwartetesErgebnis]
+- Name in plain Englisch besser lesbar
+- Beispiel
+  - _Sum_TwoNumbers_ReturnsSum()_ :(
+  - _Sum_of_two_numbers()_ :)
+
+**Guideline**
+- Keiner starken Benennungspolicy folgen
+- Benenne die Tests als würdest du es einem nicht-Programmierer-Deppen erklären, der aber die Anwendung kennt
+- Separiere Wörter, sodass sie lesbar sind
+  - bspw. durch `-`, `_`, `testTest`
+
+#### Good Practices - Parameterized Tests
+**Motivation:**
+- Ein Test ist meistens nicht genug um eine Verhaltens-Unit zu beschreiben
+  - hat div. Komponenten
+- Beispiel:
+  - Online-Store mit Lieferfunktion
+    - constraint: frühstes Lieferdatum ist übermorgen
+      - ```
+        public void Delivery_with_a_past_date_is_invalid()
+        public void Delivery_for_today_is_invalid()
+        public void Delivery_for_tomorrow_is_invalid()
+        public void The_soonest_delivery_date_is_two_days_from_now()
+        ```
+      - das viel zu viel
+      - wenn man das mal auf größere Probleme anwendet wirds nicht besser
+
+**Parametrisierte Tests:** {id="parametrized-tests"}
+- gruppieren Tests
+- meiste xUnit Frameworks haben Funktion dafür
+- Beispiel in .NET:
+  - ![image_610.png](image_610.png)
+- Also:
+  - weniger Test-Code
+  - Aber:
+    - schwerer herauszufinden, welche Fakten die Methode repräsentiert
+    - je mehr Parameter, desto schwieriger
+
+