1 changed files with 449 additions and 196 deletions
-
645Lerntagebuch.md
@ -1,253 +1,506 @@ |
|||||
## Lerntagebuch |
## Lerntagebuch |
||||
|
|
||||
# Mein Lerntagebuch für Programmiermethoden und -werkzeuge |
|
||||
Das ist ein Beispiel wie ein Lerntagebuch aussehen könnte. |
|
||||
|
|
||||
## SU 01(21.10.2021) |
|
||||
### Lernziel |
|
||||
- Organisatorisches |
|
||||
- Versionskontrollsysteme allgemein |
|
||||
- git |
|
||||
- Vorteile |
|
||||
- wie lege ich ein Repository an |
|
||||
- vim (ein paar alltägliche Befehle) |
|
||||
|
|
||||
### Erkenntnis |
|
||||
Versionskontrolle werden wir im Projekt einsetzen, um |
|
||||
zu jeder Zeit den Entwicklungsstand einzusehen und paralleles Arbeiten an Dateien zu ermöglichen. Sollten Probleme an der Software auftreten, können wir zu einem funktionierenden Stand wechseln und durch das Commit-Log die Ursache ausfindig machen. |
|
||||
Außerdem kann ich als Developer mit den gelernten vim-Befehlen vor den anderen flexen. |
|
||||
|
|
||||
### 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 |
|
||||
Dateien verschwinden von der Ausgabe, wenn ich `git commit` |
|
||||
ausführe. Rote Dateien werden mit `git add` grün. |
|
||||
|
|
||||
### Mitteilung |
|
||||
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) |
|
||||
### Lernziel |
|
||||
- SSH-Zugriff-zum-git-server-konfigurieren |
|
||||
- SSH key pair generieren |
|
||||
- oeffentlichen SSH key im Repository eintragen |
|
||||
- Lokale Kopie auf SSh-Zugriff umstellen |
|
||||
- Neue lokale Repositories |
|
||||
|
|
||||
### Erkenntnis |
|
||||
- einen ssh-key erstellt |
|
||||
- öffentlichen Schlüssel zu gogs hinzugefügt |
|
||||
- Master Branch erstellt |
|
||||
|
|
||||
### kritik |
|
||||
man muss die git-Konfigurationsdatei überprüfen und den url-Link in gitea/gogs SSH-Remote-Repository-Link ändern. |
|
||||
|
Das ist ein Beispiel wie ein Lerntagebuch aussehen könnte. |
||||
|
|
||||
### Mitteilung |
|
||||
|
|
||||
|
## SU 01(21.10.2021) |
||||
|
|
||||
|
### Lernziel |
||||
|
|
||||
## Übung 02 (2.11.2022) |
|
||||
### Lernziel |
|
||||
- legen Sie in Ihrem Repository die Datei Programmierparadigmen.md an. |
|
||||
- Analysieren Sie die Programmiersprachen Java,C,Python,go,JavaScript und TypeScript hinsichtlich der in der Vorlesung genannten Kriterien und Schreiben sie ihre Analyse in Stichpunkten in die neu erstellte datei. |
|
||||
- Suchen Sie im Internet nach weiteren Programmierprinzipien und dokumentieren sie diese (Acronym, Langbezeichnung, Beschreibung) in der Obigen Datei. |
|
||||
|
|
||||
### Erkenntnis |
|
||||
Ein neu Datei als Programmierparadigmen.md an Gitea hochgeladet. |
|
||||
|
|
||||
### Kritik |
|
||||
Programmierprinzipien |
|
||||
- SOLID |
|
||||
- STUPID |
|
||||
- KISS (Keep It Simple & Stupid) |
|
||||
- FCoH (Favor Composition over Inheritance) |
|
||||
- YAGNI (You Ain't Gonna Need It) |
|
||||
- IOC (Inversion Of Control) |
|
||||
- DI (Dependency Injection) |
|
||||
- DRY (Don't Repeat Yourself) |
|
||||
- DYC (Document Your Code) |
|
||||
- Clean Code at All Cost |
|
||||
|
|
||||
### Mitteilung |
|
||||
|
|
||||
## Übung 3 (16.11.2022) |
|
||||
|
|
||||
clone link https://gogs.informatik.hs-fulda.de/Programmiermethoden_und_werkzeuge-public/UebungDebugging.git |
|
||||
|
|
||||
### Lernziel |
|
||||
- Führen Sie die Übung entsprechend den Anweisungen in der README.md-Datei aus. |
|
||||
- Debugging |
|
||||
|
- Organisatorisches |
||||
|
- Versionskontrollsysteme allgemein |
||||
|
- git |
||||
|
- Vorteile |
||||
|
- wie lege ich ein Repository an |
||||
|
- vim (ein paar alltägliche Befehle) |
||||
|
|
||||
|
### Erkenntnis |
||||
|
|
||||
|
Versionskontrolle werden wir im Projekt einsetzen, um |
||||
|
zu jeder Zeit den Entwicklungsstand einzusehen und paralleles Arbeiten an Dateien zu ermöglichen. Sollten Probleme an der Software auftreten, können wir zu einem funktionierenden Stand wechseln und durch das Commit-Log die Ursache ausfindig machen. |
||||
|
Außerdem kann ich als Developer mit den gelernten vim-Befehlen vor den anderen flexen. |
||||
|
|
||||
|
### 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 |
||||
|
Dateien verschwinden von der Ausgabe, wenn ich `git commit` |
||||
|
ausführe. Rote Dateien werden mit `git add` grün. |
||||
|
|
||||
|
### Mitteilung |
||||
|
|
||||
|
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) |
||||
|
|
||||
|
### Lernziel |
||||
|
|
||||
|
- SSH-Zugriff-zum-git-server-konfigurieren |
||||
|
- SSH key pair generieren |
||||
|
- oeffentlichen SSH key im Repository eintragen |
||||
|
- Lokale Kopie auf SSh-Zugriff umstellen |
||||
|
- Neue lokale Repositories |
||||
|
|
||||
### Erkenntnis |
|
||||
**Task 1 Uebung 1** |
|
||||
- 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 |
|
||||
- number 5 passed check: true% |
|
||||
|
### Erkenntnis |
||||
|
|
||||
enter an integer number: 34 |
|
||||
- input: 34, Schleifenvariable: 2, Ergebnis 0 |
|
||||
- number 34 passed check: false% |
|
||||
|
- einen ssh-key erstellt |
||||
|
- öffentlichen Schlüssel zu gogs hinzugefügt |
||||
|
- Master Branch erstellt |
||||
|
|
||||
enter an integer number: 89 |
|
||||
- nachdem schleifen es gibt |
|
||||
- number 89 passed check: true% |
|
||||
|
### kritik |
||||
|
|
||||
Nachdem einen Breakpoint an ziele 35 und zahl 45 eingeben es gibt |
|
||||
- die Inhalte der Variablen sind nextInt: 45, i:2, ergebnis:1 |
|
||||
|
man muss die git-Konfigurationsdatei überprüfen und den url-Link in gitea/gogs SSH-Remote-Repository-Link ändern. |
||||
|
|
||||
Nochmal lauft das Programm im Debug-modes und eingeben zahl ist 47 |
|
||||
- die Inhalte der Variablen sind nextInt: 47, i:2, ergebnis:1 dann nextInt: 47, i:3, ergebnis:2 |
|
||||
- am ende nextInt: 47, i:46 Ergebnis:1 check: true |
|
||||
|
### Mitteilung |
||||
|
|
||||
**Task 2 Uebung 2** |
|
||||
|
--------------------------- |
||||
|
|
||||
Ö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. |
|
||||
|
## Übung 02 (2.11.2022) |
||||
|
|
||||
- **natürliche zahlen sind 45, 14, 89 ergebnis sind False ingesamt** |
|
||||
|
### Lernziel |
||||
|
|
||||
|
- legen Sie in Ihrem Repository die Datei Programmierparadigmen.md an. |
||||
|
- Analysieren Sie die Programmiersprachen Java,C,Python,go,JavaScript und TypeScript hinsichtlich der in der Vorlesung genannten Kriterien und Schreiben sie ihre Analyse in Stichpunkten in die neu erstellte datei. |
||||
|
- Suchen Sie im Internet nach weiteren Programmierprinzipien und dokumentieren sie diese (Acronym, Langbezeichnung, Beschreibung) in der Obigen Datei. |
||||
|
|
||||
- setzen Sie einen BreakPoint in Zeile 40 |
|
||||
- Starten Sie das Programm wie bisher |
|
||||
- Starten Sie das Programm im Debug-Modus und geben Sie die Zahl 45 ein |
|
||||
- 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** |
|
||||
|
### Erkenntnis |
||||
|
|
||||
- in welcher Zeile steht der Debugger? 34->36 |
|
||||
- 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 |
|
||||
- nextInt: **16**, count: **4** ergebnis: **false** |
|
||||
|
Ein neu Datei als Programmierparadigmen.md an Gitea hochgeladet. |
||||
|
|
||||
**Beenden Sie den Debugger (*"Terminate"*)** |
|
||||
|
### Kritik |
||||
|
|
||||
### Kritik |
|
||||
|
Programmierprinzipien |
||||
|
|
||||
### Mitteilung |
|
||||
|
- SOLID |
||||
|
- STUPID |
||||
|
- KISS (Keep It Simple & Stupid) |
||||
|
- FCoH (Favor Composition over Inheritance) |
||||
|
- YAGNI (You Ain't Gonna Need It) |
||||
|
- IOC (Inversion Of Control) |
||||
|
- DI (Dependency Injection) |
||||
|
- DRY (Don't Repeat Yourself) |
||||
|
- DYC (Document Your Code) |
||||
|
- Clean Code at All Cost |
||||
|
|
||||
|
### Mitteilung |
||||
|
|
||||
|
---------------------------- |
||||
|
|
||||
|
## Übung 3 (16.11.2022) |
||||
|
|
||||
|
clone link <https://gogs.informatik.hs-fulda.de/Programmiermethoden_und_werkzeuge-public/UebungDebugging.git> |
||||
|
|
||||
|
### Lernziel |
||||
|
|
||||
|
- Führen Sie die Übung entsprechend den Anweisungen in der README.md-Datei aus. |
||||
|
- Debugging |
||||
|
|
||||
## Uebung 4 (23.11.2022) |
|
||||
### Lernziel |
|
||||
Lokale Respository |
|
||||
- Stage und Historic |
|
||||
- Merge |
|
||||
- rebase |
|
||||
|
### Erkenntnis |
||||
|
|
||||
|
**Task 1 Uebung 1** |
||||
|
|
||||
|
- 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 |
||||
|
- number 5 passed check: true% |
||||
|
|
||||
### Erkenntnis |
|
||||
|
enter an integer number: 34 |
||||
|
|
||||
### kritik |
|
||||
|
- input: 34, Schleifenvariable: 2, Ergebnis 0 |
||||
|
- number 34 passed check: false% |
||||
|
|
||||
### Mitteilung |
|
||||
|
enter an integer number: 89 |
||||
|
|
||||
|
- nachdem schleifen es gibt |
||||
|
- number 89 passed check: true% |
||||
|
|
||||
|
Nachdem einen Breakpoint an ziele 35 und zahl 45 eingeben es gibt |
||||
|
|
||||
## SU 07 (07.12.2022) |
|
||||
|
- die Inhalte der Variablen sind nextInt: 45, i:2, ergebnis:1 |
||||
|
|
||||
### Lernziel |
|
||||
- Relvante Literatur |
|
||||
- Motivation |
|
||||
- Grundlagen |
|
||||
- Testmethodologie |
|
||||
- TestProzess |
|
||||
- Psychologische Aspekte |
|
||||
|
|
||||
### Erkenntnis |
|
||||
**Testmethodoligie - Bestandteile eine Tests** |
|
||||
|
Nochmal lauft das Programm im Debug-modes und eingeben zahl ist 47 |
||||
|
|
||||
|
- die Inhalte der Variablen sind nextInt: 47, i:2, ergebnis:1 dann nextInt: 47, i:3, ergebnis:2 |
||||
|
- am ende nextInt: 47, i:46 Ergebnis:1 check: true |
||||
|
|
||||
|
**Task 2 Uebung 2** |
||||
|
|
||||
|
Ö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. |
||||
|
|
||||
|
- **natürliche zahlen sind 45, 14, 89 ergebnis sind False ingesamt** |
||||
|
|
||||
|
- setzen Sie einen BreakPoint in Zeile 40 |
||||
|
- Starten Sie das Programm wie bisher |
||||
|
- Starten Sie das Programm im Debug-Modus und geben Sie die Zahl 45 ein |
||||
|
- 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** |
||||
|
|
||||
|
- in welcher Zeile steht der Debugger? 34->36 |
||||
|
- 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 |
||||
|
- nextInt: **16**, count: **4** ergebnis: **false** |
||||
|
|
||||
|
**Beenden Sie den Debugger (*"Terminate"*)** |
||||
|
|
||||
|
### Kritik |
||||
|
|
||||
|
### Mitteilung |
||||
|
|
||||
|
|
||||
|
------------------------------------- |
||||
|
|
||||
|
## Uebung 4 (23.11.2022) |
||||
|
|
||||
|
### Lernziel |
||||
|
|
||||
|
Lokale Respository |
||||
|
|
||||
|
- Stage und Historic |
||||
|
- Merge |
||||
|
- rebase |
||||
|
|
||||
|
### Erkenntnis |
||||
|
|
||||
|
### kritik |
||||
|
|
||||
|
### Mitteilung |
||||
|
|
||||
|
------------------------------------------------- |
||||
|
|
||||
|
## SU 07 (07.12.2022) |
||||
|
|
||||
|
### Lernziel |
||||
|
|
||||
|
- Relvante Literatur |
||||
|
- Motivation |
||||
|
- Grundlagen |
||||
|
- Testmethodologie |
||||
|
- TestProzess |
||||
|
- Psychologische Aspekte |
||||
|
|
||||
|
### Erkenntnis |
||||
|
|
||||
|
**Testmethodoligie - Bestandteile eine Tests** |
||||
|
|
||||
|
- Stichprobe |
||||
|
- Testfälle |
||||
|
- Testdaten |
||||
|
- Testobekt |
||||
|
- Testumgebung |
||||
|
- Testziel |
||||
|
- Soll-/Ist- Wertvergliech |
||||
|
|
||||
|
**Testziele** |
||||
|
|
||||
|
- Fehler aufzeigen |
||||
|
- Qualität erfassen |
||||
|
- Vertrauen erhöhen |
||||
|
- Grenzen ermitteln |
||||
|
|
||||
|
**Testebenen** |
||||
|
|
||||
|
- Anwendung/System |
||||
|
- Teilsystem/Modul |
||||
|
- Codeebene/Unit |
||||
|
|
||||
|
**Testpyramide** |
||||
|
|
||||
|
- GUI Tests (end to end tests) |
||||
|
business logik überprufen, functions und kommiunikation mit anderen components überprufen. |
||||
|
- Integration tests |
||||
|
|
||||
|
- Component / Contract Tests |
||||
|
- Unit Tests |
||||
|
|
||||
|
**Testnamen** |
||||
|
|
||||
|
Test werden benannt nach: |
||||
|
|
||||
|
- Ziel (Integration Test, Lasttest) |
||||
|
- Methode (Regressionstest) |
||||
|
- Testgegenstand (UI-test, Module-test, Unit-test) |
||||
|
- Level (Systemtest) |
||||
|
- Personen (Entwicklertest, Anwendertest) |
||||
|
- Testabdeckung (Komplettest, partieller Test) |
||||
|
|
||||
|
**Qualitätskosten** |
||||
|
|
||||
- Stichprobe |
|
||||
- Testfälle |
|
||||
|
- High Cost -> Poor Quality -> Failure Costs |
||||
|
- High Cost -> Exceptional Quality -> Sweet Spot (prevention & Appraisal Cost) |
||||
|
- Low Cost -> Exceptional Quality -> prevention & Appraisal Cost |
||||
|
|
||||
|
**Testprozess** |
||||
|
|
||||
|
**Testprozess - Ablauf** |
||||
|
|
||||
|
**Testprozess - Plannung** |
||||
|
|
||||
|
**Testprozess - Analyse & design** |
||||
|
|
||||
|
- basiert auf Anforderungsdokumentation |
||||
|
- Testspezifikation |
||||
|
- Testfaelle |
||||
|
- Kritikalitaet |
||||
- Testdaten |
- Testdaten |
||||
- Testobekt |
|
||||
- Testumgebung |
|
||||
- Testziel |
|
||||
- Soll-/Ist- Wertvergliech |
|
||||
|
- Testumgebung |
||||
|
- Ausfuehrungsreihenfolge |
||||
|
- Infrastruktur |
||||
|
- Testkriterium |
||||
|
|
||||
|
**Testprozess - Testausfuerung** |
||||
|
|
||||
|
Testlog |
||||
|
|
||||
|
- aufgetretenes Fehlverhalten |
||||
|
- Fehlerkategorie (high/medium/low) |
||||
|
|
||||
|
**Testprozess - Testnachbereitung** |
||||
|
|
||||
|
- Testreport |
||||
|
- Zusammenfassung Testausfuehrungen |
||||
|
- Vergleich mit frueheren Testlaeufen |
||||
|
- Entscheidung ueber Lieferfaehigkeit |
||||
|
|
||||
|
### kritik |
||||
|
|
||||
|
### Mitteilung |
||||
|
|
||||
|
---------------------------------------- |
||||
|
|
||||
|
## SU (14.12.2022) |
||||
|
|
||||
|
### Lernziel |
||||
|
|
||||
|
- Automatisiertes Testen von Software |
||||
|
- Motivation |
||||
|
- Grundlegen |
||||
|
- UnitTests |
||||
|
- Anforderungen an zu testenden Code |
||||
|
|
||||
|
### Erkenntnis |
||||
|
|
||||
|
**Motivation** - *warum automatiestert Testen?* |
||||
|
Probleme manuellen Testens |
||||
|
|
||||
|
- Testfähigkeit der Software |
||||
|
- Wiederholbarkeit |
||||
|
- nachlassende Aufmerksamkeit |
||||
|
- unterschiedlicher Kontetn verschiedener Tester:Innen |
||||
|
- Überlappungen / Lücken bei der Testausführung |
||||
|
- Fehlerzustände Testen |
||||
|
- Wissen der Tester:Innen |
||||
|
- unvollständige Testdokumentation, setzt implizites Wissen voraus |
||||
|
- Bedienung der Anwendung |
||||
|
- Bedienung der Testwerkzeuge |
||||
|
- Aufwand |
||||
|
- langsam |
||||
|
- Arbeitszeit |
||||
|
|
||||
|
**Motivation** - *Qualitätskosten* |
||||
|
|
||||
|
**Motivation** - *Gründe gegen Automatisiert Tests* |
||||
|
|
||||
|
Wie kann ich das testen? |
||||
|
|
||||
|
- nur User interface |
||||
|
- prettier Code |
||||
|
- Keine Tests |
||||
|
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?* |
||||
|
|
||||
**Testziele** |
|
||||
|
- häufige Wiederholung |
||||
|
- hohe Anzahl |
||||
|
- hohe Kritikatiltät |
||||
|
- hohe Stabilität |
||||
|
- Unittests |
||||
|
- Modultests |
||||
|
- Integrationstest |
||||
|
- Regressionstest |
||||
|
- ApplicationTests |
||||
|
- Integrationstest |
||||
|
- Regressionstest |
||||
|
- Lasttests |
||||
|
- Acceptance-Tests |
||||
|
|
||||
- Fehler aufzeigen |
|
||||
- Qualität erfassen |
|
||||
- Vertrauen erhöhen |
|
||||
- Grenzen ermitteln |
|
||||
|
**Unterschied Application / Module-Tests zu UnitTests** |
||||
|
*Appplication und Module* |
||||
|
|
||||
**Testebenen** |
|
||||
|
- werden spät im entwicklungsprozess ausgeführt |
||||
|
- Testwerkzeuge sind Komplex |
||||
|
- sind aufwendig zu warten |
||||
|
- zeigen, das ein Fehler existiert |
||||
|
|
||||
- Anwendung/System |
|
||||
- Teilsystem/Modul |
|
||||
- Codeebene/Unit |
|
||||
|
*UnitTest* |
||||
|
|
||||
**Testpyramide** |
|
||||
|
- 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. |
||||
|
|
||||
- GUI Tests (end to end tests) |
|
||||
business logik überprufen, functions und kommiunikation mit anderen components überprufen. |
|
||||
- Integration tests |
|
||||
|
-------------------------- |
||||
|
|
||||
- Component / Contract Tests |
|
||||
- Unit Tests |
|
||||
|
***UnitTests*** |
||||
|
|
||||
**Testnamen** |
|
||||
|
Was macht ein Unittest? |
||||
|
|
||||
Test werden benannt nach: |
|
||||
- Ziel (Integration Test, Lasttest) |
|
||||
- Methode (Regressionstest) |
|
||||
- Testgegenstand (UI-test, Module-test, Unit-test) |
|
||||
- Level (Systemtest) |
|
||||
- Personen (Entwicklertest, Anwendertest) |
|
||||
- Testabdeckung (Komplettest, partieller Test) |
|
||||
|
- 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. |
||||
|
- Ein einzelner Test prüft genau eine Erwartung an die Unit. |
||||
|
- Unittests verhindern ungewollte Änderungen. |
||||
|
|
||||
|
|
||||
|
***Wie schreibt man einen guten Unittest?*** |
||||
|
|
||||
|
**F**ast - schnell |
||||
|
Kann nach jedem speichern ausgeführt werden ohne den Arbeitsablauf zu verzögern. |
||||
|
|
||||
|
- primitive Vorbereitung (setup) |
||||
|
- Abhängigkeiten durch Test-Doubles ersetzen |
||||
|
|
||||
|
**I**ndependent - unabhängig |
||||
|
Jeder Test kann einzeln ausgeführt werden. |
||||
|
|
||||
|
- kein Test schafft Voraussetzungen für nachfolgende |
||||
|
- Test können in beliebiger Reihenfolge laufen |
||||
|
|
||||
|
**R**epeatable - wiederholbar |
||||
|
Jede Ausführung (ohne Änderung des getesteten Codes) führt zum selben |
||||
|
Ergebnis. |
||||
|
|
||||
|
- nicht von zufälligen Größen abhängig |
||||
|
- kein Einfluß durch Änderungen an anderen Units |
||||
|
- kein Einfluß durch Testumgebung (Netzwerk, Festplatte, Position in der Verzeichnisstruktur) |
||||
|
|
||||
|
**S**elfevaluating - selbstauswertend |
||||
|
Das Testergebnis ist eindeutig und binär. |
||||
|
|
||||
|
- Erfolg oder Mißerfolg sind eindeutig erkennbar |
||||
|
- Ergebnis muss nicht in Logdateien o.ä. gesucht werden |
||||
|
- Ergebnis kann automatisiert weiter verarbeitet werden |
||||
|
|
||||
|
**T**imely - zeitnah |
||||
|
Unittests entstehen zeitnah zum getesteten Code. |
||||
|
|
||||
|
- Code first |
||||
|
Tests werden nach dem zu testenden Code geschrieben. |
||||
|
- Test first |
||||
|
Tests werden vor dem zu testenden Code geschrieben. |
||||
|
- Test Driven Developement |
||||
|
Test und verifizierter Code entstehen gleichzeitig |
||||
|
|
||||
|
**R**eadable - was bedeutet *lesbar*? |
||||
|
|
||||
**Qualitätskosten** |
|
||||
|
- was wird getestet |
||||
|
Name des Test drückt Vorbedingungen und erwartetes Ergebnis aus. |
||||
|
- Kurz |
||||
|
wiederkehrende Vorbereitungen im Methoden auslagern |
||||
|
- Welche Eigenschaften der Parameter sind wichtig? |
||||
|
Explizit Variablen für Parameterwerte anlegen |
||||
|
Variablennamen sorgsam wählen |
||||
|
- Welche Eigenschaften der Ergebnisse sind wichtig? |
||||
|
Explizit Variablen für Ergebnisse anlegen |
||||
|
Variablennamen sorgsam wählen |
||||
|
verifizierungsmethoden mit sprechenden Namen. |
||||
|
|
||||
- High Cost -> Poor Quality -> Failure Costs |
|
||||
- High Cost -> Exceptional Quality -> Sweet Spot (prevention & Appraisal Cost) |
|
||||
- Low Cost -> Exceptional Quality -> prevention & Appraisal Cost |
|
||||
|
**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? |
||||
|
- Ersetzten von Abhängigkeiten(Mocking) |
||||
|
- (weitestgehend) keine Logik in Tests |
||||
|
|
||||
**Testprozess** |
|
||||
|
**F**ast |
||||
|
(schone erklärt) |
||||
|
|
||||
**Testprozess - Ablauf** |
|
||||
|
**M**aintainable - Was bedeutet wartbar? |
||||
|
|
||||
|
- Stabilität gegenüber Anderungen in anderen Units |
||||
|
Abhängigkeiten ersetzen |
||||
|
- stabil gegen Änderungen in der Unit selbst |
||||
|
eine einzelne Anforderung (nicht Codestelle) testen. |
||||
|
|
||||
**Testprozess - Plannung** |
|
||||
|
---------------------------- |
||||
|
|
||||
**Testprozess - Analyse & design** |
|
||||
|
***Anforderungen an zu testenden Code*** |
||||
|
|
||||
- basiert auf Anforderungsdokumentation |
|
||||
- Testspezifikation |
|
||||
- Testfaelle |
|
||||
- Kritikalitaet |
|
||||
- Testdaten |
|
||||
- Testumgebung |
|
||||
- Ausfuehrungsreihenfolge |
|
||||
- Infrastruktur |
|
||||
- Testkriterium |
|
||||
|
- Was verbessert die Testbarkeit? |
||||
|
- Isolieren einer Unit |
||||
|
- Isolation Ermöglichen |
||||
|
|
||||
**Testprozess - Testausfuerung** |
|
||||
|
---------- |
||||
|
|
||||
|
*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) |
||||
|
|
||||
|
die wichtigsten "Clean Code" Regeln sind: |
||||
|
|
||||
|
- Separation of Concerns / single responsibility |
||||
|
Erzeugung von Objekten der Abhängigkeiten ist keine aufgabe der Geschäftslogik! |
||||
|
- Dependency Inversion |
||||
|
- Tell! Don´t ask. |
||||
|
- Law of Demeter (Don´t talk to strangers) |
||||
|
vermeide "message chaining" (nicht mit "fluent API" verwechseln) |
||||
|
|
||||
|
*Arten von Test-Doubles* |
||||
|
|
||||
|
- Stub |
||||
|
- leere Implementierung einen Schnittstelle, üblicher Weise generiert |
||||
|
- Fake |
||||
|
- alternative Implementierung einer Schnittstelle oder Erweiterung einer existerenden Implementierung. |
||||
|
- exterm vereinfachtes Verhalten(keine Logik) |
||||
|
- Mock |
||||
|
- "aufgemotztes" Fake |
||||
|
- konfigurierbares Verhalten |
||||
|
- Verifizierung vom Methodenaufrufen und der übergebenen Parameter |
||||
|
|
||||
Testlog |
|
||||
- aufgetretenes Fehlverhalten |
|
||||
- Fehlerkategorie (high/medium/low) |
|
||||
|
|
||||
**Testprozess - Testnachbereitung** |
|
||||
|
|
||||
- Testreport |
|
||||
- Zusammenfassung Testausfuehrungen |
|
||||
- Vergleich mit frueheren Testlaeufen |
|
||||
- Entscheidung ueber Lieferfaehigkeit |
|
||||
|
|
||||
### kritik |
|
||||
|
|
||||
### Mitteilung |
|
||||
|
*Was Ermöglicht die Ersetzung von Abhängigkeiten?* |
||||
|
|
||||
|
- trenne Instanyiierung der Abhängigkeiten von der Geschäftslogik |
||||
|
- 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) |
||||
|
|
||||
|
|
||||
|
*Schreibe "Clean Code"* |
||||
|
|
||||
|
- programmiere gegen Schnittstellen |
||||
|
- SoC/ SRP (Feature envy) |
||||
|
- Law of Demeter |
||||
|
- DRY |
||||
|
- same level of abstraction |
||||
|
|
||||
|
|
||||
|
### kritik |
||||
|
|
||||
|
### Mitteilung |
||||
Write
Preview
Loading…
Cancel
Save
Reference in new issue