Philipp Hartmann
2 years ago
1 changed files with 80 additions and 0 deletions
@ -0,0 +1,80 @@ |
|||||
|
Lerntagebuch für Programmiermethoden und -werkzeuge von Philipp Hartmann |
||||
|
|
||||
|
# Su8 14.12.2022 |
||||
|
|
||||
|
## Lernziele (Was waren die wesentlichen Inhaltlichen Punkte der letzten Vorlesung) |
||||
|
|
||||
|
# Motivation |
||||
|
- Vorteile von automatisierten Tests |
||||
|
- Nachteile von automatisierten Tests |
||||
|
- Qualitätskosten |
||||
|
# Grundlagen |
||||
|
- welche Tests automatisieren |
||||
|
- häufige Wiederholungen |
||||
|
- hohe Anzahl |
||||
|
- hohe Kritikalität |
||||
|
- hohe Stabilität |
||||
|
# Unterschied Application/Module-Tests zu UnitTests |
||||
|
Application und Module Test |
||||
|
- werden spät im Entwicklungsprozess ausgeführt |
||||
|
- Testwerkzeuge sind komplex |
||||
|
- sind aufwendig zu warten |
||||
|
- zeigen, das ein Fehler existiert, aber nicht wo |
||||
|
UnitTest |
||||
|
- laufen früh im Entwicklungsprozess |
||||
|
- Werkzeuge haben einfache API |
||||
|
- sind stabil gegen Änderungen |
||||
|
- zeigen welche Anforderung nicht erfüllt wird, wo der Fehler existiert und unter welchen Bedingungen er auftritt |
||||
|
# UnitTests |
||||
|
- ausführbare Dokumentation |
||||
|
- testen keinen Code |
||||
|
- verifizieren von außen beobachtbares gewünschtes Verhalten von Code |
||||
|
- ein einzelner Test prüft genau eine Erwartung an die Unit |
||||
|
- verhindern ungtewollte Änerungen |
||||
|
# Wie man einen guten UnitTest schreibt |
||||
|
- Fast |
||||
|
- Independent |
||||
|
- Repeatable |
||||
|
- Selfevaluating |
||||
|
- Timely |
||||
|
- Readable |
||||
|
- Trustworthy |
||||
|
- Fast |
||||
|
- Maintainable |
||||
|
# Anforderungen an zu testenden Code |
||||
|
- Was verbessert die Testbarkeit |
||||
|
- Isolieren einer Unit |
||||
|
- Isolation Ermöglichen |
||||
|
# Testbarkeit von produktivem Code (die wichtigsten "Clean Code" Regeln) |
||||
|
- Seperation of concerns / singe resposibility |
||||
|
- Dependency Inversion |
||||
|
- Tell! Don´t ask |
||||
|
- Law of Demeter |
||||
|
# Arten von Test-Doubles |
||||
|
- Stub (leere Implementierung einer Schnittstelle) |
||||
|
- Fake (alternative Implementierung einer Schnittstelle oder Erweiterung einer existierenden Implementierung) |
||||
|
- Mock (konfigurierares Verhalten) |
||||
|
# Was Ermöglicht die Ersetzung von Abhängigkeiten? |
||||
|
- trenne Instanziierung der Abhängigkeiten von der Geschäftslogik |
||||
|
- vermeide den Aufruf des new Operators |
||||
|
- bereitstellen von "seams" (Nahtstellen) |
||||
|
- keine static Methoden |
||||
|
- keine final Methoden |
||||
|
- vermeide Singleton Pattern |
||||
|
# Clean Code schreiben |
||||
|
- programmiere gegen Schnittstellen |
||||
|
- Law of Demeter |
||||
|
- DRY |
||||
|
- same level of abstraction |
||||
|
|
||||
|
## Erkenntnis (Was kann ich für das Gruppenprojekt anwenden -2-3 Sätze) |
||||
|
Jetzt kenne ich UnitTests und weiß wozu sie gut sind. |
||||
|
Außerdem kenne ich jetzt die wichtigsten Regeln des "Clean Code" und kann sie besser anwenden. |
||||
|
|
||||
|
## Wiederholung (Einen Begriff/Ein Thema erklären -2-3 Sätze) |
||||
|
UnitTests prüfen, ob die vom Entwickler geschriebenen Komponenten wie vorgesehen funktionieren. |
||||
|
Deswegen strebt man eine sehr häufige Ausführung der Tests vor. |
||||
|
Dies erreicht man, wenn die Tests vollständig automatisiert sind. |
||||
|
|
||||
|
## Kritik (Kritik oder Lob für den Dozenten - Optimal 2-3 Sätze |
||||
|
- Nichts |
Write
Preview
Loading…
Cancel
Save
Reference in new issue