@ -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 <https://gogs.informatik.hs-fulda.de/Programmiermethoden_und_werkzeug
**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: 3, Ergebnis 2
- input: 5, Schleifenvariable: 4, Ergebnis 1
@ -118,7 +117,7 @@ enter an integer number: 34
enter an integer number: 89
- 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
@ -133,7 +132,7 @@ Nochmal lauft das Programm im Debug-modes und eingeben zahl ist 47
Ö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**
@ -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
- this: **Uebung2@8**
- 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
- 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
**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.
