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