Advanced Design and Programming - 2. Teil [ID:9944]
50 von 640 angezeigt

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 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

Tags

Open Source Isolated Testing Contract Property-Based Acceptance
Einbetten
Wordpress FAU Plugin
iFrame
Teilen