@ -21,7 +21,7 @@ Außerdem kann ich als Developer mit den gelernten vim-Befehlen vor den anderen
### Kritik
### 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`
Dateien verschwinden von der Ausgabe, wenn ich `git commit`
ausführe. Rote Dateien werden mit `git add` grün.
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
weg. Aber wenn mich irgendwas stört oder begeistert, kann ich es
hier anmerken.
hier anmerken.
-----------------------------------
---
## Uebung 01 (27.10.2022)
## Uebung 01 (27.10.2022)
@ -43,7 +42,7 @@ hier anmerken.
- oeffentlichen SSH key im Repository eintragen
- oeffentlichen SSH key im Repository eintragen
- Lokale Kopie auf SSh-Zugriff umstellen
- Lokale Kopie auf SSh-Zugriff umstellen
- Neue lokale Repositories
- Neue lokale Repositories
### Erkenntnis
### Erkenntnis
- einen ssh-key erstellt
- einen ssh-key erstellt
@ -56,7 +55,7 @@ man muss die git-Konfigurationsdatei überprüfen und den url-Link in gitea/gogs
### Mitteilung
### Mitteilung
---------------------------
---
## Übung 02 (2.11.2022)
## Übung 02 (2.11.2022)
@ -87,7 +86,7 @@ Programmierprinzipien
### Mitteilung
### Mitteilung
----------------------------
---
## Übung 3 (16.11.2022)
## Übung 3 (16.11.2022)
@ -102,9 +101,9 @@ clone link <https://gogs.informatik.hs-fulda.de/Programmiermethoden_und_werkzeug
**Task 1 Uebung 1**
**Task 1 Uebung 1**
- Nachdem Aktivieren Sie die Zeilen 36 bis 38 durch entfernen der beiden *slashes*.
**Ausgaben sind:**
enter an integer number: 5
- Nachdem Aktivieren Sie die Zeilen 36 bis 38 durch entfernen der beiden _slashes_.
**Ausgaben sind:**
enter an integer number: 5
- input: 5, Schleifenvariable: 2, Ergebnis 1
- input: 5, Schleifenvariable: 2, Ergebnis 1
- input: 5, Schleifenvariable: 3, Ergebnis 2
- input: 5, Schleifenvariable: 3, Ergebnis 2
- input: 5, Schleifenvariable: 4, Ergebnis 1
- input: 5, Schleifenvariable: 4, Ergebnis 1
@ -118,7 +117,7 @@ enter an integer number: 34
enter an integer number: 89
enter an integer number: 89
- nachdem schleifen es gibt
- nachdem schleifen es gibt
- number 89 passed check: true%
- number 89 passed check: true%
Nachdem einen Breakpoint an ziele 35 und zahl 45 eingeben es gibt
Nachdem einen Breakpoint an ziele 35 und zahl 45 eingeben es gibt
@ -133,7 +132,7 @@ Nochmal lauft das Programm im Debug-modes und eingeben zahl ist 47
Öffnen Sie das programm `Uebung2.java` im Editor
Öffnen Sie das programm `Uebung2.java` im Editor
- Starten Sie das Programm mehrfach (*"run as Java Application"*) und geben Sie verschiedenen natürliche Zahlen ein.
- Starten Sie das Programm mehrfach (_"run as Java Application"_) und geben Sie verschiedenen natürliche Zahlen ein.
- **natürliche zahlen sind 45, 14, 89 ergebnis sind False ingesamt**
- **natürliche zahlen sind 45, 14, 89 ergebnis sind False ingesamt**
@ -143,23 +142,22 @@ Nochmal lauft das Programm im Debug-modes und eingeben zahl ist 47
- Notieren Sie die Inhalte der Variablen (this) nextInt: 23
- Notieren Sie die Inhalte der Variablen (this) nextInt: 23
- this: **Uebung2@8**
- this: **Uebung2@8**
- count: **3**
- count: **3**
- Notieren Sie die Anzahl der Einträge in der *Debug View* (this): **this, count, in, out in total 4 mit Zwischenüberschritt**
- Notieren Sie die Anzahl der Einträge in der _Debug View_ (this): **this, count, in, out in total 4 mit Zwischenüberschritt**
- in welcher Zeile steht der Debugger? 34->36
- in welcher Zeile steht der Debugger? 34->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**
- nextInt: **45**, count: **2**
- in welcher Zeile steht der Debugger? **40**
- 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
**Motivation** - *Gründe gegen Automatisiert Tests*
**Motivation** - _Gründe gegen Automatisiert Tests_
Wie kann ich das testen?
Wie kann ich das testen?
- nur User interface
- nur User interface
- prettier Code
- prettier Code
- Keine Tests
- 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.
- UnitTests schreiben ist eine Fertigkeit und muss ständig geübt werden.
- Technische Voraussetzungen müssen sichergestellt sein.
- Technische Voraussetzungen müssen sichergestellt sein.
- Team und Vorgesetzte müssen automatisiertes Testen unterstützen.
- 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.
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
- häufige Wiederholung
- hohe Anzahl
- hohe Anzahl
@ -343,35 +341,34 @@ Für jedes Verhalten, das wir bei einer Person beobachten ist deren Umfeld perfe
- Acceptance-Tests
- Acceptance-Tests
**Unterschied Application / Module-Tests zu UnitTests**
**Unterschied Application / Module-Tests zu UnitTests**
*Appplication und Module*
_Appplication und Module_
- werden spät im entwicklungsprozess ausgeführt
- werden spät im entwicklungsprozess ausgeführt
- Testwerkzeuge sind Komplex
- Testwerkzeuge sind Komplex
- sind aufwendig zu warten
- sind aufwendig zu warten
- zeigen, das ein Fehler existiert
- zeigen, das ein Fehler existiert
*UnitTest*
_UnitTest_
- laufen früh im Entwikclungsprozess (idealer Weise nach jedem Spiechern)
- laufen früh im Entwikclungsprozess (idealer Weise nach jedem Spiechern)
- Werkzeuge haben einfache API
- Werkzeuge haben einfache API
- sind stabil gegen Änderungen(anderer Units)
- sind stabil gegen Änderungen(anderer Units)
- zeigen welche Anforderung nicht erfüllt wird, wo der Fahler existiert und unter welchen Bedigungen er auftritt.
- zeigen welche Anforderung nicht erfüllt wird, wo der Fahler existiert und unter welchen Bedigungen er auftritt.
--------------------------
---
***UnitTests***
**_UnitTests_**
Was macht ein Unittest?
Was macht ein Unittest?
- Unittests sind ausführbare Dokumentation.
- Unittests sind ausführbare Dokumentation.
- Unittest testen keinen Code.
- Unittest testen keinen Code.
- Unittest verifizieren von außen beobachtbares gewünschtes Verhalten von 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.
- Ein einzelner Test prüft genau eine Erwartung an die Unit.
- Unittests verhindern ungewollte Änderungen.
- Unittests verhindern ungewollte Änderungen.
***Wie schreibt man einen guten Unittest?***
**_Wie schreibt man einen guten Unittest?_**
**F**ast - schnell
**F**ast - schnell
Kann nach jedem speichern ausgeführt werden ohne den Arbeitsablauf zu verzögern.
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.
Unittests entstehen zeitnah zum getesteten Code.
- Code first
- Code first
Tests werden nach dem zu testenden Code geschrieben.
Tests werden nach dem zu testenden Code geschrieben.
- Test first
- Test first
Tests werden vor dem zu testenden Code geschrieben.
Tests werden vor dem zu testenden Code geschrieben.
- Test Driven Developement
- 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
- was wird getestet
Name des Test drückt Vorbedingungen und erwartetes Ergebnis aus.
Name des Test drückt Vorbedingungen und erwartetes Ergebnis aus.
@ -424,16 +421,16 @@ Test und verifizierter Code entstehen gleichzeitig
Variablennamen sorgsam wählen
Variablennamen sorgsam wählen
verifizierungsmethoden mit sprechenden Namen.
verifizierungsmethoden mit sprechenden Namen.
**T**rustworthy - Was bedeutet vertrauenswürdig?
**T**rustworthy - Was bedeutet vertrauenswürdig?
- Geschäftsanforderungen erfüllt
- Geschäftsanforderungen erfüllt
Wurde tatsächlich implementiert, was der Kunde wollte?
Wurde tatsächlich implementiert, was der Kunde wollte?
- technisch
- technisch
Wird der Produktivcode tatsächlich ausgefühtrt?
Wird der Produktivcode tatsächlich ausgefühtrt?
- "test first"
- "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)
- Ersetzten von Abhängigkeiten(Mocking)
- (weitestgehend) keine Logik in Tests
- (weitestgehend) keine Logik in Tests
**F**ast
**F**ast
(schone erklärt)
(schone erklärt)
@ -441,21 +438,21 @@ Test und verifizierter Code entstehen gleichzeitig
**M**aintainable - Was bedeutet wartbar?
**M**aintainable - Was bedeutet wartbar?
- Stabilität gegenüber Anderungen in anderen Units
- Stabilität gegenüber Anderungen in anderen Units
Abhängigkeiten ersetzen
Abhängigkeiten ersetzen
- stabil gegen Änderungen in der Unit selbst
- 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?
- Was verbessert die Testbarkeit?
- Isolieren einer Unit
- Isolieren einer Unit
- Isolation Ermöglichen
- 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)
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)
- Law of Demeter (Don´t talk to strangers)
vermeide "message chaining" (nicht mit "fluent API" verwechseln)
vermeide "message chaining" (nicht mit "fluent API" verwechseln)
*Arten von Test-Doubles*
_Arten von Test-Doubles_
- Stub
- Stub
- leere Implementierung einen Schnittstelle, üblicher Weise generiert
- leere Implementierung einen Schnittstelle, üblicher Weise generiert
@ -479,30 +476,105 @@ die wichtigsten "Clean Code" Regeln sind:
- "aufgemotztes" Fake
- "aufgemotztes" Fake
- konfigurierbares Verhalten
- konfigurierbares Verhalten
- Verifizierung vom Methodenaufrufen und der übergebenen Parameter
- 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
- 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)
- Bereitstellen von "seams" (Nahtstellen)
- dependencz injection
- dependencz injection
- Getter mit geringer Sichtbarkeit
- Getter mit geringer Sichtbarkeit
- keine **static** (public) Methoden
- keine **static** (public) Methoden
- keine **final** (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
- programmiere gegen Schnittstellen
- SoC/ SRP (Feature envy)
- SoC/ SRP (Feature envy)
- Law of Demeter
- Law of Demeter
- DRY
- DRY
- same level of abstraction
- same level of abstraction
### kritik
### kritik
### Mitteilung
### 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.
