Ja, vier Themen habe ich mir rausgesucht. Das sind nicht die einzigen Themen, die man sich hätte
raussuchen können. Ich denke, es sind zumindest wichtige Themen. Ob es die wichtigsten, da
unterscheiden sich ja immer, scheiden sich die Geister. Mein Lieblingsthema habe ich auf den
dritten Punkt gepackt, also im schlimmsten Fall fällt dann eben der letzte weg, aber die beiden
ersten, die sehr wichtig sind, sind dann auf jeden Fall drin. Okay, die Tafeln gibt es hier,
okay. Ich habe jetzt nach dem Flipchart gesucht, aber mal gucken, liegt hier auch irgendwo Kreide?
Also ich werde es auch knapp halten. Ja, was passiert, wenn man, was wir bisher gesehen haben,
das waren Testfälle dieser Form, also das war eine, was ihr ob ans hinten sehen kann, eine Komponente,
die heißt A und dann gibt es A-Tests, das ist dann sozusagen mein Testmodul und das greift
direkt darauf zu und das testet das und ruft Funktionen auf, die da drinstecken. Im wirklichen
Leben ist es nur meistens anders, im wirklichen Leben haben wir eher ein Geflecht an Abhängigkeiten,
das greift irgendwie auf die Datenbank zu und hier haben wir noch unsere Funktion E und F und das hier
geht es über das Internet auf irgendeinen Webservice, ja, irgend sowas. So sieht es
eher realistisch aus und das Problem ist jetzt, wenn ich A testen will und irgendwie dann naiv
dran gehe, dann brauche ich, um A zu testen, B und C und für B brauche ich D und die Datenbank und
für C brauche ich noch E und F und ich brauche diesen Webservice, der irgendwo dazu gegriffen
wird. Ja und dann sind wir ganz schnell in diesem Bereich der integrierten Tests mit all den
Problemen, die ich vorhin an der Testpyramide beschrieben habe. Und man kann das natürlich
dann eben auch, das war der falsche Lappen, man kann das dann natürlich auch anders machen.
Jetzt kommt die große. Dankeschön, das war bestimmt der Plastikmüll, den ich da geworfen habe. Man kann
das natürlich auch anders machen oder nicht, natürlich weiß ich nicht, aber man kann das
anders machen und die Idee ist eben auch, dass selbst die Komponenten, die eben nicht isoliert
sind im normalen Leben, die sozusagen mit anderen Komponenten zusammenarbeiten, deswegen programmieren
wir ja auch objektorientiert, weil wir Aufgaben abgeben können an andere Objekte. Das eine Objekt
delegiert die Aufgabe an einen Service oder was auch immer, dass man die trotzdem versucht,
in Isolation zu testen. Das ist sozusagen die Idee und das Konstrukt, was man da anwendet,
das nennt man ganz gerne Test-Doubles oder wenn sie lesen, finden sie Mocks, Dummies, Dubs,
also alle möglichen Begriffe. Ich werde nachher so eine kleine Hierarchie zeigen an Begrifflichkeiten.
Ich benutze sozusagen als den generellen Begriff ein Test-Double, so wie das Double für die
Schauspieler, das Body-Double, wenn man sich nackt zeigen muss als Schauspieler oder wenn man das
Hochhaus runterspringen muss, macht man das auch nicht selbst, das Test-Double. Die Idee hinter
einem Test-Double ist eigentlich recht simpel. Alle Abhängigkeiten, also alles, was mein Objekt,
das ich testen möchte, noch benutzt, wovon es abhängig ist, ersetzt sich für die Dauer des
Tests durch so einen Double. Das ist die Idee dahinter. Diese Doubles sollen einfach sein,
die will ich kontrollieren können in meinem Test selbst und damit habe ich ganz viele Vorteile.
Wenn mein Double beispielsweise am Endeffekt eine Datenbank ersetzt, die irgendwo dann darunter käme,
ist mein Test mit dem Double viel schneller. Ich kann viel besser kontrollieren Sonderfälle,
wo ein Fehler auftritt, eine Exception kommt, das sind alles Dinge, die ich sozusagen viel besser
in der Hand habe, als wenn ich mit den echten Objekten arbeiten würde. Eine Sache, die oft
unterschätzt wird, ist, wenn ich integrierte Objekte teste und ich möchte alle Fälle,
die auftreten können, in ihrer Kombinatorik testen, kann ich das, wenn ich die Objekte
einzeln habe, alle Aspekte pro Objekt testen. Ich habe also eine Summe aller Aspekte, wenn ich
die Anzahl der Testfälle betrachte. Wenn ich das über Integration hinweg mache, habe ich das
Produkt der Aspekte, die davor kommen. Also ich bin in der Anzahl meiner Tests, kann ich deutlich
nach unten gehen, wenn ich dieses isolierte Test betreibe. Lernt man im Studium immer noch UML?
Ist das noch was, was man irgendwie... Ja, ja, also dann können Sie das alles lesen. Ich hoffe,
ich habe die aktuellen Pfeilarten benutzt. Hier eine Benutztbeziehung und hier eine
Implementierungsbeziehung. Also was hier steht, ist völlig trivial. Es gibt ein Ding, das wir
testen wollen und das arbeitet mit irgendeinem Kollaborator zusammen. Und wir haben natürlich
irgendwie das richtige Objekt dafür, den echten Kollaborator. Und wir haben dann eben dieses
Presenters
Dipl.-Inf. Johannes Link
Zugänglich über
Offener Zugang
Dauer
01:02:31 Min
Aufnahmedatum
2018-12-17
Hochgeladen am
2018-12-21 11:32:56
Sprache
de-DE
Developer Testing Part 2: Advanced Topics