13 KiB
Lerntagebuch
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.
Mitteilung
Ü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
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%
enter an integer number: 34
- input: 34, Schleifenvariable: 2, Ergebnis 0
- number 34 passed check: false%
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
- die Inhalte der Variablen sind nextInt: 45, i:2, ergebnis:1
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
- 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
- Testumgebung
- Ausfuehrungsreihenfolge
- Infrastruktur
- Testkriterium
- Testfaelle
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?
- häufige Wiederholung
- hohe Anzahl
- hohe Kritikatiltät
- hohe Stabilität
- Unittests
- Modultests
- Integrationstest
- Regressionstest
- ApplicationTests
- Integrationstest
- Regressionstest
- Lasttests
- Acceptance-Tests
Unterschied Application / Module-Tests zu UnitTests Appplication und Module
- werden spät im entwicklungsprozess ausgeführt
- Testwerkzeuge sind Komplex
- sind aufwendig zu warten
- zeigen, das ein Fehler existiert
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
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.
- Ein einzelner Test prüft genau eine Erwartung an die Unit.
- Unittests verhindern ungewollte Änderungen.
Wie schreibt man einen guten Unittest?
Fast - schnell Kann nach jedem speichern ausgeführt werden ohne den Arbeitsablauf zu verzögern.
- primitive Vorbereitung (setup)
- Abhängigkeiten durch Test-Doubles ersetzen
Independent - unabhängig Jeder Test kann einzeln ausgeführt werden.
- kein Test schafft Voraussetzungen für nachfolgende
- Test können in beliebiger Reihenfolge laufen
Repeatable - 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)
Selfevaluating - 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
Timely - 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
Readable - was bedeutet lesbar?
- 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.
Trustworthy - 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
Fast (schone erklärt)
Maintainable - 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.
Anforderungen an zu testenden Code
- Was verbessert die Testbarkeit?
- Isolieren einer Unit
- Isolation Ermöglichen
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
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