diff --git a/.Lerntagebuch.md.swp b/.Lerntagebuch.md.swp new file mode 100644 index 0000000..3cbb242 Binary files /dev/null and b/.Lerntagebuch.md.swp differ diff --git a/Lerntagebuch.md b/Lerntagebuch.md index fdf07fa..822c834 100644 --- a/Lerntagebuch.md +++ b/Lerntagebuch.md @@ -21,7 +21,7 @@ Außerdem kann ich als Developer mit den gelernten vim-Befehlen vor den anderen ### Kritik -`git status` zeigt mir einen groben Zustand meines Git-Repositorys an. Manchmal werden Dateien oder Verzeichnisse dort rot oder grün angezeigt. Die grünen +`git status` zeigt mir einen groben Zustand meines Git-Repositorys an. Manchmal werden Dateien oder Verzeichnisse dort rot oder grün angezeigt. Die grünen Dateien verschwinden von der Ausgabe, wenn ich `git commit` ausführe. Rote Dateien werden mit `git add` grün. @@ -31,8 +31,7 @@ an die Dozierenden Da dieser Punkt optional ist, lasse ich ihn weg. Aber wenn mich irgendwas stört oder begeistert, kann ich es hier anmerken. ------------------------------------ - +--- ## Uebung 01 (27.10.2022) @@ -43,7 +42,7 @@ hier anmerken. - oeffentlichen SSH key im Repository eintragen - Lokale Kopie auf SSh-Zugriff umstellen - Neue lokale Repositories - + ### Erkenntnis - einen ssh-key erstellt @@ -56,7 +55,7 @@ man muss die git-Konfigurationsdatei überprüfen und den url-Link in gitea/gogs ### Mitteilung ---------------------------- +--- ## Übung 02 (2.11.2022) @@ -87,7 +86,7 @@ Programmierprinzipien ### Mitteilung ----------------------------- +--- ## Übung 3 (16.11.2022) @@ -102,9 +101,9 @@ clone link 36 -- Notieren Sie die Anzahl der Einträge in der *Debug View* (this) +- Notieren Sie die Anzahl der Einträge in der _Debug View_ (this) - nextInt: **45**, count: **2** - in welcher Zeile steht der Debugger? **40** -- Notieren Sie die Anzahl der Einträge in der *Debug View* (this) false +- Notieren Sie die Anzahl der Einträge in der _Debug View_ (this) false - nextInt: **16**, count: **4** ergebnis: **false** -**Beenden Sie den Debugger (*"Terminate"*)** +**Beenden Sie den Debugger (_"Terminate"_)** ### Kritik ### Mitteilung - -------------------------------------- +--- ## Uebung 4 (23.11.2022) @@ -177,7 +175,7 @@ Lokale Respository ### Mitteilung -------------------------------------------------- +--- ## SU 07 (07.12.2022) @@ -188,7 +186,7 @@ Lokale Respository - Grundlagen - Testmethodologie - TestProzess -- Psychologische Aspekte +- Psychologische Aspekte ### Erkenntnis @@ -218,7 +216,7 @@ Lokale Respository **Testpyramide** - GUI Tests (end to end tests) -business logik überprufen, functions und kommiunikation mit anderen components überprufen. + business logik überprufen, functions und kommiunikation mit anderen components überprufen. - Integration tests - Component / Contract Tests @@ -238,7 +236,7 @@ Test werden benannt nach: **Qualitätskosten** - High Cost -> Poor Quality -> Failure Costs -- High Cost -> Exceptional Quality -> Sweet Spot (prevention & Appraisal Cost) +- High Cost -> Exceptional Quality -> Sweet Spot (prevention & Appraisal Cost) - Low Cost -> Exceptional Quality -> prevention & Appraisal Cost **Testprozess** @@ -272,12 +270,12 @@ Testlog - Zusammenfassung Testausfuehrungen - Vergleich mit frueheren Testlaeufen - Entscheidung ueber Lieferfaehigkeit - + ### kritik ### Mitteilung ----------------------------------------- +--- ## SU (14.12.2022) @@ -291,7 +289,7 @@ Testlog ### Erkenntnis -**Motivation** - *warum automatiestert Testen?* +**Motivation** - _warum automatiestert Testen?_ Probleme manuellen Testens - Testfähigkeit der Software @@ -308,25 +306,25 @@ Probleme manuellen Testens - langsam - Arbeitszeit -**Motivation** - *Qualitätskosten* +**Motivation** - _Qualitätskosten_ -**Motivation** - *Gründe gegen Automatisiert Tests* +**Motivation** - _Gründe gegen Automatisiert Tests_ Wie kann ich das testen? - nur User interface - prettier Code - Keine Tests -Persönliche, technische und Soziale Voraussetzungen + Persönliche, technische und Soziale Voraussetzungen - UnitTests schreiben ist eine Fertigkeit und muss ständig geübt werden. - Technische Voraussetzungen müssen sichergestellt sein. - Team und Vorgesetzte müssen automatisiertes Testen unterstützen. Für jedes Verhalten, das wir bei einer Person beobachten ist deren Umfeld perfekt daraus ausgereichtet, dieses Verhalten zu fördern. --------------------------- +--- -**Grundlagen** - *Wleche Tests automatisierien?* +**Grundlagen** - _Wleche Tests automatisierien?_ - häufige Wiederholung - hohe Anzahl @@ -343,35 +341,34 @@ Für jedes Verhalten, das wir bei einer Person beobachten ist deren Umfeld perfe - Acceptance-Tests **Unterschied Application / Module-Tests zu UnitTests** -*Appplication und Module* +_Appplication und Module_ - werden spät im entwicklungsprozess ausgeführt - Testwerkzeuge sind Komplex - sind aufwendig zu warten - zeigen, das ein Fehler existiert -*UnitTest* +_UnitTest_ - laufen früh im Entwikclungsprozess (idealer Weise nach jedem Spiechern) - Werkzeuge haben einfache API - sind stabil gegen Änderungen(anderer Units) - zeigen welche Anforderung nicht erfüllt wird, wo der Fahler existiert und unter welchen Bedigungen er auftritt. --------------------------- +--- -***UnitTests*** +**_UnitTests_** Was macht ein Unittest? - Unittests sind ausführbare Dokumentation. - Unittest testen keinen Code. - Unittest verifizieren von außen beobachtbares gewünschtes Verhalten von Code. -Sie prüfne Rüchgabewerte und kommuikation mit anderen Units des zu testenden Codes als Reacktion auf die übergebenen Parameter und/oder den Reaktionen der anderen Units. + Sie prüfne Rüchgabewerte und kommuikation mit anderen Units des zu testenden Codes als Reacktion auf die übergebenen Parameter und/oder den Reaktionen der anderen Units. - Ein einzelner Test prüft genau eine Erwartung an die Unit. - Unittests verhindern ungewollte Änderungen. - -***Wie schreibt man einen guten Unittest?*** +**_Wie schreibt man einen guten Unittest?_** **F**ast - schnell Kann nach jedem speichern ausgeführt werden ohne den Arbeitsablauf zu verzögern. @@ -404,13 +401,13 @@ Das Testergebnis ist eindeutig und binär. Unittests entstehen zeitnah zum getesteten Code. - Code first -Tests werden nach dem zu testenden Code geschrieben. + Tests werden nach dem zu testenden Code geschrieben. - Test first -Tests werden vor dem zu testenden Code geschrieben. + Tests werden vor dem zu testenden Code geschrieben. - Test Driven Developement -Test und verifizierter Code entstehen gleichzeitig + Test und verifizierter Code entstehen gleichzeitig -**R**eadable - was bedeutet *lesbar*? +**R**eadable - was bedeutet _lesbar_? - was wird getestet Name des Test drückt Vorbedingungen und erwartetes Ergebnis aus. @@ -424,16 +421,16 @@ Test und verifizierter Code entstehen gleichzeitig Variablennamen sorgsam wählen verifizierungsmethoden mit sprechenden Namen. -**T**rustworthy - Was bedeutet vertrauenswürdig? +**T**rustworthy - Was bedeutet vertrauenswürdig? - Geschäftsanforderungen erfüllt Wurde tatsächlich implementiert, was der Kunde wollte? - technisch Wird der Produktivcode tatsächlich ausgefühtrt? - "test first" - Schlägt der Test aus dem richtigen Grund fehl? + Schlägt der Test aus dem richtigen Grund fehl? - Ersetzten von Abhängigkeiten(Mocking) - - (weitestgehend) keine Logik in Tests + - (weitestgehend) keine Logik in Tests **F**ast (schone erklärt) @@ -441,21 +438,21 @@ Test und verifizierter Code entstehen gleichzeitig **M**aintainable - Was bedeutet wartbar? - Stabilität gegenüber Anderungen in anderen Units -Abhängigkeiten ersetzen + Abhängigkeiten ersetzen - stabil gegen Änderungen in der Unit selbst -eine einzelne Anforderung (nicht Codestelle) testen. + eine einzelne Anforderung (nicht Codestelle) testen. ----------------------------- +--- -***Anforderungen an zu testenden Code*** +**_Anforderungen an zu testenden Code_** - Was verbessert die Testbarkeit? - Isolieren einer Unit - Isolation Ermöglichen ----------- +--- -*Testbarkeit von production Code* +_Testbarkeit von production Code_ Qualität des producktivem code (im Sinne von "Clean Code" und dem "S.O.L.I.D" prinzip) beeinflußt die Qualität der Tests (im Sinne der RTFM - Anforderungen) @@ -468,7 +465,7 @@ die wichtigsten "Clean Code" Regeln sind: - Law of Demeter (Don´t talk to strangers) vermeide "message chaining" (nicht mit "fluent API" verwechseln) -*Arten von Test-Doubles* +_Arten von Test-Doubles_ - Stub - leere Implementierung einen Schnittstelle, üblicher Weise generiert @@ -479,30 +476,105 @@ die wichtigsten "Clean Code" Regeln sind: - "aufgemotztes" Fake - konfigurierbares Verhalten - Verifizierung vom Methodenaufrufen und der übergebenen Parameter - -*Was Ermöglicht die Ersetzung von Abhängigkeiten?* + +_Was Ermöglicht die Ersetzung von Abhängigkeiten?_ - trenne Instanyiierung der Abhängigkeiten von der Geschäftslogik -- vermeide den Aufruf des ***new*** Operators +- vermeide den Aufruf des **_new_** Operators - Bereitstellen von "seams" (Nahtstellen) - dependencz injection - Getter mit geringer Sichtbarkeit - keine **static** (public) Methoden - keine **final** (public) Methoden -- vermeide *Singelton Pattern* (nicht Singelton als Konzept) +- vermeide _Singelton Pattern_ (nicht Singelton als Konzept) - -*Schreibe "Clean Code"* +_Schreibe "Clean Code"_ - programmiere gegen Schnittstellen - SoC/ SRP (Feature envy) - Law of Demeter - DRY - same level of abstraction - ### kritik ### Mitteilung ----------------------------------- +--- + +## SU (21.12.2022) + +### Lernziel + +Test Driven Development + +- Relevante Litratur - Growing Object-Oriented Software, Guided by Tests von Steve Freeman, art of unit Testing von Michael Feathers +- Motivation +- Grundlagen + +### Erkenntnis + +**Motivation** - _Qualitaetskosten_ + +**Motivation** - _Welche Tests automatisieren?_ + +- Haeufige Wiederholdung +- hohe Anzahl +- hohe Kritikatiltaet +- hohe Stabilitaet + Unittests sind die vorherrschende Testart + +_Wie schreibt man einen guten UnitTest?_ + +- Fast +- Independent +- Repeatable +- Selfevaluating +- **Timely** +- Readable +- **Trustworthy** +- Fast +- Maintainable + +Timely - zeitnah + +**Unittests entstehen zeitnah zum getesteten Code.** + +- Code First + Test werden nach dem zu testenden Code geschreiben. +- Test first + Test werden vor dem zu testenden Code geschreiben. +- Test Driven Development + Test und verifizierter Code entstehen gleichzeitig. + +**Motivation** - _Fazit_ + +Unittests sind die am häfigsten zu erstellenden automatisierten Tests und Test Driven Development ist die geeignetste Vorgehensweise zu deren Erstellung. + +**Grundlagen** - _Testabdeckung_ + +- oft als KPI (key performance indicator) missbraucht +- wichtig für ddie Beurteilung der Vertrauenswürdigkeit des Testhareness +- TDD führt zu hoher testabdeckung, aber nicht zu 100% ( realistisch 70% bis 90%) +- **TDD führt zu 100% Anforderungsabdeckung** + +**Grundlagen** - _Vorgehen_ + +- Formalisierung des Entwicklungsprozesses +- inkrementelle Entwickliung des Code in "Baby-steps" +- verhindert _Flow_ + +**Grundlagen** - _TDD micro cycle_ + +- Schreiben einen neuen Test, gerade so viel dass er fehl schlägt ( nicht kompilieren ist Fehlschlagen). +- Schreiben gerade so viel Produktivcode, dass der Test erfüllt wird. + Zukünftige Anforderungen nicht beachten! (so simpel wie möglich, alles ist erlaubt, Transformations-Prämissen beachten). +- Verbessere den Code (Produktion und Test), ohne einen Test zu brechen und ohne neue Funktionalität (Geschäftslogik) hinzuzufügen. + +### kritik + +Schreibe Code im TDD cycle. + +### Mitteilung + +---