From 5e65e45fdf9dad8ac2c5ae444c51dd2e02f4e7b1 Mon Sep 17 00:00:00 2001 From: Simernjeett singh Date: Wed, 21 Dec 2022 10:46:15 +0100 Subject: [PATCH] Vorlesung 21.12.2022 erklaert --- .Lerntagebuch.md.swp | Bin 0 -> 16384 bytes Lerntagebuch.md | 188 ++++++++++++++++++++++++++++++------------- 2 files changed, 130 insertions(+), 58 deletions(-) create mode 100644 .Lerntagebuch.md.swp diff --git a/.Lerntagebuch.md.swp b/.Lerntagebuch.md.swp new file mode 100644 index 0000000000000000000000000000000000000000..3cbb24255a56fa53e676293b342497ef0c5b6f2f GIT binary patch literal 16384 zcmeI3ZH#1DS;w#LBJYc$5KK%w)8k5arK@_nduN#)iJPA3o|)R2o^GaQre`);c5YRj zx^=ehOL@<|UDIt?MOciYpa$5O0E;jI0|^9$RdLX`^-b5rudE+jVxnIZ@B>j2K!4A< zw_dt;nZ*PXldVerT~+s<^PKZM=XtN&&0|;Vo9cnuF^|_zdfs1u>W^CY9QC|=Pk3Hi z?}@82nFMAMm`PwJftdtm z5|~L~CV`m*W)hf5U?zc?1pW^s;Pb2bY3S}q1AyQENA>@=-r#xP1b+(t1bhs96nqeT z0PKUSU>j_JUjW~~$Me1iz5)In{293YdY&TyEpQF&fWLU1=e-Nm!8z~%I03%%TIPU1 z2A=`%0lxv>4Fb>s*TFSV1wRG;={27BCGaHp5O@N-7xcg{fjMvlycxU+eB#xf_Z0X& z@Ihcf3a*1|;5>K;+y$zy^1P3{((^tH-Uprl>)4h+DXVw(O$jp5bcg1T7561P2A7nZuP!J z)fiFVEk$rr!R|)MuHyIjAGp}+eN&4aKeU$PW3m)-e36w{f4tK2OATI~8ocsSgQs~| z{=qC9_bQdO+y=g!jvW2TN(IuR6JG0OW|zl(xY=!X(xzG;vS8y_;oydva+hNCI0kaVJS5KQp~r*H+!LPqnt5e*7uYSvO(n zN73@}b5Oe4&zqrXEfpM&IjIFE`(;^Nl?<$^`Q`g-%geQuV=F5QaD9hYvFS~d!9@s* zBBRrxM)gm#0p(|EEe!c=GZEhP(`tS_X}Jfu)b%7!-KYh*b?Lg?ir<>4OS-R_C%3H* zJMM0sn_Q0JskMh^cuco4lf-hbz6H^Gyvu`KTv1ycXvSHZgmUxx+S!ZDg_c?~Li}tJ z$G*C#G3a_GBhH*o&Z+q`{%#_hiTa5(LRlpc6c?mZllgH=%h>bvMnlb?*SgPSG%o7n zOMX!`vb=BFGN5t!%65HSK5Sj!-J5zMt)CjswQqD>i0nLcO^^78M#MT-r5=PBa3mlsH}tl0~`DXr-o~x&2+<>+AAs*Tj}h zWTTyLl>3AZiTB52VcrMR(0q^qQRm@NxJ7I7Dqe9Y5&l%zQFV+ws>qs&9D4$w)jF* zjL?`Ux7O_fE3ckU;*JUO6yK4=w(VTc@HTO-pAK(J1QW@K%gWQRdOEn=raC(#FX**K?Ub*ySkl)Vt;Q=Ts^W*{Rsrth0n zv`U zM6bjm))OKXyotuF`*I0()V7$7O8TN>eyEtgs6xr1+-%b=9pH4#ApCL6*iKDdLb(c; z0Z|^|721)>)D5Ji{C4|>3eZ)!a8|`lar~|BfZRa7;JIbvWzMiza45TW^IHi|2WK}t z_r+#@mfIT&Hx^{9k(MeJq=~qNhjRvC4v{FH70)}R^A>T|&~0=&g2!^7qb(J}yQi6r#xikR_6b?CLP-!>R~JSSKK0 zf8wupO;kOlJDRjqB$B$@u;LtVC)77Z39z!qw210q0)iW{5oZI_>PZy01?zCWpIa?H zSsa77tuSO6tJYFdC|L_l7;z0nokqi_198SIp&E&JN*8HJ-6Kq`IGje($p$_S7t_m9 z%@DL}_;f7U*??mZLdZN)9nmDTXsl!ncOnCFD;!1Xtz3H7MsbPW$f9~737m3XNv(tv zNv%34hY3{V!b{ELU?f$r7@gz^c!=`+WN}OzPyLuih1rDF*}iNqj|%U4FwP=qHP0v{ z<6~fOJG@nJPe63?m!x38(MpggjEB)vuEQ6N$5loz=b zNAHd%)6TOW7~)C&|F_h9`_zz9|Ld~&dzO0si{NqaF0ccn-aiGT&i_yFH{b){5%6~K zD)5ig_g?|O4Sow;1y{fd_%CYwe*=FGJ_B;_5K!Rf!JEO|;4bhSwf)z?E%1Ku2$%<@M-Y7;CH~g!LNgNf=9qtspW5jKLEcEZh+T;Z&TlY9ef$2;8(yk zumiTiD}e`|q^=LZ4R8)DfPbcbe;#}ed=_-T32+biHnsadfX{*71P_5aI0ue_CGc7x zwY}8z&w;-Je+j+{3r_Z8I73){(nf|4khV0?Gb;tIaQg;_fcZ% zIylzHsfH3sRnk#@(~`!yx)T3NLCW6?{y=W6<8{e`xX?&WFR8|*ZAwOp)SMuuF7jBa_+oDXY`CqUK{l zs#Kh#JCXvB%ID`ItG38(B)C~dlO&KFP{>MJvS&yKq_T5)Ub9Q#5tu->2B}g0cUJ1r z;jK<)!z7S0yRt*z+Zd-OWIV*Y4H^vDzR;3+YX@mPSba9$kI3 znk2rPnEctHELV63$=P}eGUSyzqLTkC>k14wiHG-y-tceZDyxvi*znsKC`K$Jw#iR??_P7 z+4Cwgw)8q~55*pxFr>MNI!vN~xX`*y!a`OPLwAL@+;BBSsnu6dN5+dw;P{&85f!fU z2vbWwC_UlIflWyPLvfO^ufihSHl$HJ*~kk&kr#`1=FdLjmp0Rw&ymIoogzvsl+;Df z@OGSQ8B2!ml>*Mm#xnPFl?rB+0r}lU71C-_G3NaHtfG9Aqd`XVI9lmb(_09Kw^G7UrE-S3?8!NzdFN7W z7DyS{UMSVxc`D(f&<8iN@WvyM2;C{Clyz# zEAw+S6^}7B+;xLXFH6TmS}C%?dG>)#x>8uEOpM&0=m8tnDIE~$j3K|vl}bwYVL)Bj z-4pLBnmU#}DvO80yV=3;c1mH(DLB742~u|S1AvR;<6k3K<{}Y^>R(NMQH$k@vPl|{ z4ynQLmb48RuyL~=67;gkNW~6Q++6WX8=l*bUGo#Jc62DU_J%Zkk&xdRdA_O9xUBZb zImw}nf7AQl?qD2ODcfll{Sdnt&nSLAEIp)bg3^~$>S=mUa!!=u^u@>}N<*83dQpdv zaFa^$eLhe3nJmKOkZqxaZTeDp(1J!AT`g#c9uj{r7*a^dK??B+Ju!086Z#HqOjA@; zI|aB@sc64l8lH?8AAW^6h~ZT@bEo-29fc^5UNSfFCGv9@w4`xElt7v3G7%D3&P`fR jaq~28${vy^t)s?HiiTU!G>Ts6?ARs8OGlFqS36 -- Notieren Sie die Anzahl der Einträge in der *Debug View* (this) +- 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 +- Notieren Sie die Anzahl der Einträge in der _Debug View_ (this) false - nextInt: **16**, count: **4** ergebnis: **false** -**Beenden Sie den Debugger (*"Terminate"*)** +**Beenden Sie den Debugger (_"Terminate"_)** ### Kritik ### Mitteilung - -------------------------------------- +--- ## Uebung 4 (23.11.2022) @@ -177,7 +175,7 @@ Lokale Respository ### Mitteilung -------------------------------------------------- +--- ## SU 07 (07.12.2022) @@ -188,7 +186,7 @@ Lokale Respository - Grundlagen - Testmethodologie - TestProzess -- Psychologische Aspekte +- Psychologische Aspekte ### Erkenntnis @@ -218,7 +216,7 @@ Lokale Respository **Testpyramide** - GUI Tests (end to end tests) -business logik überprufen, functions und kommiunikation mit anderen components überprufen. + business logik überprufen, functions und kommiunikation mit anderen components überprufen. - Integration tests - Component / Contract Tests @@ -238,7 +236,7 @@ Test werden benannt nach: **Qualitätskosten** - High Cost -> Poor Quality -> Failure Costs -- High Cost -> Exceptional Quality -> Sweet Spot (prevention & Appraisal Cost) +- High Cost -> Exceptional Quality -> Sweet Spot (prevention & Appraisal Cost) - Low Cost -> Exceptional Quality -> prevention & Appraisal Cost **Testprozess** @@ -272,12 +270,12 @@ Testlog - Zusammenfassung Testausfuehrungen - Vergleich mit frueheren Testlaeufen - Entscheidung ueber Lieferfaehigkeit - + ### kritik ### Mitteilung ----------------------------------------- +--- ## SU (14.12.2022) @@ -291,7 +289,7 @@ Testlog ### Erkenntnis -**Motivation** - *warum automatiestert Testen?* +**Motivation** - _warum automatiestert Testen?_ Probleme manuellen Testens - Testfähigkeit der Software @@ -308,25 +306,25 @@ Probleme manuellen Testens - langsam - Arbeitszeit -**Motivation** - *Qualitätskosten* +**Motivation** - _Qualitätskosten_ -**Motivation** - *Gründe gegen Automatisiert Tests* +**Motivation** - _Gründe gegen Automatisiert Tests_ Wie kann ich das testen? - nur User interface - prettier Code - Keine Tests -Persönliche, technische und Soziale Voraussetzungen + 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?* +**Grundlagen** - _Wleche Tests automatisierien?_ - häufige Wiederholung - hohe Anzahl @@ -343,35 +341,34 @@ Für jedes Verhalten, das wir bei einer Person beobachten ist deren Umfeld perfe - Acceptance-Tests **Unterschied Application / Module-Tests zu UnitTests** -*Appplication und Module* +_Appplication und Module_ - werden spät im entwicklungsprozess ausgeführt - Testwerkzeuge sind Komplex - sind aufwendig zu warten - zeigen, das ein Fehler existiert -*UnitTest* +_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*** +**_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. + 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?*** +**_Wie schreibt man einen guten Unittest?_** **F**ast - schnell Kann nach jedem speichern ausgeführt werden ohne den Arbeitsablauf zu verzögern. @@ -404,13 +401,13 @@ Das Testergebnis ist eindeutig und binär. Unittests entstehen zeitnah zum getesteten Code. - Code first -Tests werden nach dem zu testenden Code geschrieben. + Tests werden nach dem zu testenden Code geschrieben. - Test first -Tests werden vor dem zu testenden Code geschrieben. + Tests werden vor dem zu testenden Code geschrieben. - Test Driven Developement -Test und verifizierter Code entstehen gleichzeitig + Test und verifizierter Code entstehen gleichzeitig -**R**eadable - was bedeutet *lesbar*? +**R**eadable - was bedeutet _lesbar_? - was wird getestet Name des Test drückt Vorbedingungen und erwartetes Ergebnis aus. @@ -424,16 +421,16 @@ Test und verifizierter Code entstehen gleichzeitig Variablennamen sorgsam wählen verifizierungsmethoden mit sprechenden Namen. -**T**rustworthy - Was bedeutet vertrauenswürdig? +**T**rustworthy - 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? + Schlägt der Test aus dem richtigen Grund fehl? - Ersetzten von Abhängigkeiten(Mocking) - - (weitestgehend) keine Logik in Tests + - (weitestgehend) keine Logik in Tests **F**ast (schone erklärt) @@ -441,21 +438,21 @@ Test und verifizierter Code entstehen gleichzeitig **M**aintainable - Was bedeutet wartbar? - Stabilität gegenüber Anderungen in anderen Units -Abhängigkeiten ersetzen + Abhängigkeiten ersetzen - stabil gegen Änderungen in der Unit selbst -eine einzelne Anforderung (nicht Codestelle) testen. + eine einzelne Anforderung (nicht Codestelle) testen. ----------------------------- +--- -***Anforderungen an zu testenden Code*** +**_Anforderungen an zu testenden Code_** - Was verbessert die Testbarkeit? - Isolieren einer Unit - Isolation Ermöglichen ----------- +--- -*Testbarkeit von production Code* +_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) @@ -468,7 +465,7 @@ die wichtigsten "Clean Code" Regeln sind: - Law of Demeter (Don´t talk to strangers) vermeide "message chaining" (nicht mit "fluent API" verwechseln) -*Arten von Test-Doubles* +_Arten von Test-Doubles_ - Stub - leere Implementierung einen Schnittstelle, üblicher Weise generiert @@ -479,30 +476,105 @@ die wichtigsten "Clean Code" Regeln sind: - "aufgemotztes" Fake - konfigurierbares Verhalten - Verifizierung vom Methodenaufrufen und der übergebenen Parameter - -*Was Ermöglicht die Ersetzung von Abhängigkeiten?* + +_Was Ermöglicht die Ersetzung von Abhängigkeiten?_ - trenne Instanyiierung der Abhängigkeiten von der Geschäftslogik -- vermeide den Aufruf des ***new*** Operators +- 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) +- vermeide _Singelton Pattern_ (nicht Singelton als Konzept) - -*Schreibe "Clean Code"* +_Schreibe "Clean Code"_ - programmiere gegen Schnittstellen - SoC/ SRP (Feature envy) - Law of Demeter - DRY - same level of abstraction - ### kritik ### Mitteilung ----------------------------------- +--- + +## SU (21.12.2022) + +### Lernziel + +Test Driven Development + +- Relevante Litratur - Growing Object-Oriented Software, Guided by Tests von Steve Freeman, art of unit Testing von Michael Feathers +- Motivation +- Grundlagen + +### Erkenntnis + +**Motivation** - _Qualitaetskosten_ + +**Motivation** - _Welche Tests automatisieren?_ + +- Haeufige Wiederholdung +- hohe Anzahl +- hohe Kritikatiltaet +- hohe Stabilitaet + Unittests sind die vorherrschende Testart + +_Wie schreibt man einen guten UnitTest?_ + +- Fast +- Independent +- Repeatable +- Selfevaluating +- **Timely** +- Readable +- **Trustworthy** +- Fast +- Maintainable + +Timely - zeitnah + +**Unittests entstehen zeitnah zum getesteten Code.** + +- Code First + Test werden nach dem zu testenden Code geschreiben. +- Test first + Test werden vor dem zu testenden Code geschreiben. +- Test Driven Development + Test und verifizierter Code entstehen gleichzeitig. + +**Motivation** - _Fazit_ + +Unittests sind die am häfigsten zu erstellenden automatisierten Tests und Test Driven Development ist die geeignetste Vorgehensweise zu deren Erstellung. + +**Grundlagen** - _Testabdeckung_ + +- oft als KPI (key performance indicator) missbraucht +- wichtig für ddie Beurteilung der Vertrauenswürdigkeit des Testhareness +- TDD führt zu hoher testabdeckung, aber nicht zu 100% ( realistisch 70% bis 90%) +- **TDD führt zu 100% Anforderungsabdeckung** + +**Grundlagen** - _Vorgehen_ + +- Formalisierung des Entwicklungsprozesses +- inkrementelle Entwickliung des Code in "Baby-steps" +- verhindert _Flow_ + +**Grundlagen** - _TDD micro cycle_ + +- Schreiben einen neuen Test, gerade so viel dass er fehl schlägt ( nicht kompilieren ist Fehlschlagen). +- Schreiben gerade so viel Produktivcode, dass der Test erfüllt wird. + Zukünftige Anforderungen nicht beachten! (so simpel wie möglich, alles ist erlaubt, Transformations-Prämissen beachten). +- Verbessere den Code (Produktion und Test), ohne einen Test zu brechen und ohne neue Funktionalität (Geschäftslogik) hinzuzufügen. + +### kritik + +Schreibe Code im TDD cycle. + +### Mitteilung + +---