diff --git a/Lerntagebuch.md b/Lerntagebuch.md index e3d6cfa..104fae9 100644 --- a/Lerntagebuch.md +++ b/Lerntagebuch.md @@ -1077,3 +1077,157 @@ Tests sind ein wichtiger Bestandteil der Softwareentwicklung, da durch sie Fehle ### Wiederholung Wie kommen Fehler ins Programm und wann wirken sich diese aus? Das beschreibt die Ereigniskette. Zuerst macht der Entwickler beim Schreiben des Codes eine Fehler/Error. Dieser Error ist nun als Defekt/Defect im Code vorhanden, muss sich allerdings noch nicht auswirken. Erst wenn sich der Code zur Laufzeit anders verhält als gewünscht, wird von einem Fehlverhalten/Failture gesprochen. + + + +## Vorlesung vom 2023.12.19/Übung vom 2023.12.21 + + +### Lernziel + +#### Vorlesung + + + +- Problem von manuellem Testen + - Software muss erstmal so weit sein + - Widerholbarkeit --> Aufmerksamkeit lässt nach + - Testergebnis unterschiedlich weil verschiedene Personen anderen Kenntnisstand haben + - Überlappung da mehrere Tester das Gleiche testen --> braucht zusätzliche Zeit + - schwer manuel Fehlerzustände zu testen --> verzögerte Kommunikation + - Widerholbarkeit --> muss sich mit Fachlichkeit vorraus --> setzt wissen voraus + - bedeutet potentiellen Aufwand --> menschliches Testen ist langsam + - hohe Kosten + +- Gründe gegen automatisierte Tests + - UI-Tests nach ästetischen Merkmalen + - ich bin neu in der Firma und der Vorgänger hats nicht erledigt + - ich weiß nicht wie --> muss selber dran arbeiten + + +- Persönliche Vorraussetzungen + - Units-Tests schreiben ist eine Fertigkeit die geübt werden muss + - Hardware muss fähig sein Tests auszuführen + - Testing- und Mockingframeworks müssen vorhanden sein --> sind für die meisten aber nicht für alle kostenlos + - Teams müssen Tests unterstützen --> nicht alleine gegen Strom ankämpfen + - machen leider nicht viele + +- Welche Tests automatisieren? + - welche die häufig durchlaufen + - hohe Anzahl + - hohe Wichtigkeit/Kritikalität + - Test sollten relativ stabil sein --> unten in der Testpyramide + - um so weiter unten desto eher sollte automatisiert werden + + - erst Unittests, dann Modultest und zum Schluss Applicationtests + +- 2 Kategorien von Tests + + - Moudletests --> Testingframework + - Applicationtest --> Testen mit Interface + - werden erst spät im Entwicklungsprozess ausgeführt + - sind relativ ungenau --> wo innerhalb des Moduls ist der Fehler? + - aufwendig zu warten + - schwierig mit Testwerkzeugen um zu gehen + - ist Recheneinheit korrekt eigesetzt? + +- Unittests + - können sehr früh geschrieben werden und benutzt werden + - einfache Werkzeuge zum Testen --> sind oft in gleiche Sprache geschrieben wie Programm das getestet werden soll + - sind relativ stabil weil sie nur kleinen Codeteil testen --> kleiner Teil Code ändert sich wahrscheinlich nicht, muss nicht oft gewartet werden + - zeigt an wo genau der Fehler ist/ leichte Analyse des Fehlers + - prüfen die Funktionalität + +- Was machen Unittests? + - Unittests dokumentieren erwünschtes Verhalten + - sind damit Dokumentation von Code + - der Unittest testet keinen Code, sondern Verhalten von Code + - prüft genau eine Erwartung an die Unit --> pro Erwartung ein Unittest + - verhindern ungewollte Veränderung --> durch anderen Codeteil + + +- Wie schreibt man gute Unittests? + - Fast + - möglichst viele Unittest in möglichst kurzer Zeit + - sollen nach Speichern durchlaufen + - soll max ne halbe Sekunde dauern + - damit man schnell wieder weiterarbeiten kann + - Independant + - kein Test schafft Voraussetzug für nach folgende Tests --> weiß nicht wieso der Test fehlschlägt wenn anderer Test/Programmteil nicht ausgeführt wird + - soll in beliebiger Reihenfolge laufen können + - Repeatable + - Gleiches Ergebnis bei gleichen Bedinungen + - Selfverifyable + - Ergebnis des Tests muss nicht in Logdateien gesucht werden, sondern ist gleich sichtbar + - Timely + - Code first + - Tests werden nach dem Code geschrieben + - Test first + - schlagen erst alle fehl bis Funktionalität implementiert ist + - muss überprüft werden ob was kaputt ist oder Funktionalität fehlt + - Test Driven Development + - Test und Code entstehen gleichzeitig + + + - Readable + - Test soll eindeutig beschreiben was er tut + - soll kurz sein + - sorgsame Variablenamenwahl --> sollen Funktionalität beschreiben + + + + - Trust + - erfüllt der Code die Anforderungen des Kunden? + - wird eine menschliche Aufgabe erfüllen + - wird der Produktivcode tatsächlich ausgeführt oder macht der Test nix? + - schlägt der Test aus dem richtigen Grund fehl oder gibt es einen anderen Grund? + - wenig bis gar keine Logik in Tests wenn möglich + + - Repetition + - bereits erwähnt + + - Maintainable + - gibt keine anderen Units die Einfluss auf unser Testergebnis haben + - Mocking + - Austausch von Dependencies + - unabhängig von Änderungen an der Unit selber + + - Arten von Test Doubles --> dafür damit man Unit ohne äußeren Einfluss testen kann + - Stub + - leere Implementation die zum Testen benötigt wird + - Fake + - für den Testfall relevante Testwerte/alternative Implementierung + - kein Logik vorhanden + - Mock + - alles was über Fake und Stub hinaus geht + - können für mehrere Test verwendet werden + + +- Was ermöglicht die Ersetzung von Abhängigkeiten? + - Instanzierung der Abhängigkeiten von der Logik + - bei objektorientierten Sprachen + - new Operatoren nicht verwenden in Verwendung mit anderem Code der Geschäftslogik implementiert + - seams/Nahtstellen + - dependency injection + - bei legacy code + - getter mit geringer Sichtbarkeit + - public Methoden nicht static machen + - die Methoden die für andere sichtbar gemacht werden sollen + - final nicht verwenden + - da kein überschreiben der Methode möglich + - diese beiden keywords verhindern test doubles + +- Schreibe Clean Code + - dann kann man einfach Test Doubles schreiben + - single reposponsbility + - feature envy + - Code außerhalb tut etwas was eigentlich in der Unit passieren sollte + - Law of Demeter + - same level of abstraction + - innerhalb von Codedatei zwei Arten Prozeduren + - eine Gruppe tut die Arbeit + - und andere Gruppe ruft nur auf + + + +