From 19645a939347b177154ee36310046455923f1328 Mon Sep 17 00:00:00 2001 From: fdai7377 Date: Wed, 11 Jan 2023 09:14:15 +0000 Subject: [PATCH] Letzten Auftrage aktualisiert --- Lerntagebuch.md | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/Lerntagebuch.md b/Lerntagebuch.md index d11ecdc..c43765f 100644 --- a/Lerntagebuch.md +++ b/Lerntagebuch.md @@ -164,22 +164,38 @@ A.T kann den Workflow von Bugtesting vereinfachen. Man sollte sich Zeit nehmen g Man sollte nicht den gesamten Code testen alles auf einmal. Man sollte stattdessen den Code in kleine Teile teilen und Unit Tests für die einzelnen Funktionen schreiben. Unit Tests testen auf das richtige Ergebnis, nicht wie man dort ankommt! U.T sollten independant und reihenfolgenlos ablaufen können. -# 8) Eintrag +# 8) Eintrag 21.12 ## Lernziel: +### Code testen im Kontext + +Um eine Unit zu testen muss man zuerst sich ein Test Environment zusammen stellen. Hier wird die Unit mit Fakes und Mocks umschlossen. Dieses Test Environment ist wichtig zu erstellen bei Unit Tests, da Code immer im Kontext steht. Ohne Kontext - entweder echt oder falsch- kann die Unit nicht funktionieren. + ## Erkenntnis: +Wenn eine bestimmte Unit in einem komplexem Environment steht sollte man nicht aufgaben mit Unit testen stattdessen sollte man sich die Mühe machen Mock Ups zu programmieren. + ## Wiederholung: +Ein Stub ist eine leere Implementierung einer Schnittstelle. Ein Fake ist eine alternative Implementierung einer Schnittstelle oder Erweiterung einer existierenden Implementierung. Ein Mock ist ein ein komplizierter Fake, der konfigurierbar ist und bei dem Methodenaufrufe und übergebene Parameter verifizieren kann. -# 9) Eintrag +# 9) Eintrag 28.12 ## Lernziel: +### Beim Testen Sweet Spot finden + +Testen sollte immer im Kontext zum Projekt, zur Firma und zu den Kosten/Gewinn abgewogen werden. Testen kostet Geld und Zeit aber ein Produkt voll mit Bugs und Fehlern kostet der Firma auch Geld,Zeit und Anerkennung. Deswegen sollte man einen Sweet Spot finden zwischen Zeit- und Geldaufwand.beiden erreicht. + ## Erkenntnis: +Wenn man testet sollte man zeitnah zum geschriebenen Code testen. Nicht vorher, nicht nachher. So geht man sicher, dass sich keine Bugs einschleichen bevor man es merkt. + ## Wiederholung: +Testabdeckung führt meist zu 90% Abdeckung, aber nie 100%! Weil das einfach nicht realistisch ist. Man sollte auch nicht den Fehler machen Testabdeckung als key performance indicator zu nehmen. + +# 10) Eintrag 11.01