Es scheint so, als haben wir ja nun über den
gesamten Durchlauf über das ganze Vorgehen gesprochen,
doch einen ganz wichtigen Punkt bin ich Ihnen bis jetzt im Detail schuldig geblieben.
Nämlich, wie funktioniert denn das, dieses Entkoppeln und Abhängigkeiten auflösen?
Das möchte ich in diesem Abschnitt mit Ihnen durchgehen.
Wir haben dazu eine Folie, aber zunächst erst mal die Fragen dazu.
Wir werden zu der Frage 19 und 20 hier sprechen,
fake und Mock-Objekte. Das ist nämlich schon die Lösung für
dieses App-Entkoppeln und Auflösen von Abhängigkeiten
Wir hatten das entkoppeln, Abhängigkeiten auflösen, das ist letztlich das,
was wir hier auf dieser Überschrift durch Trennung dargestellt haben.
Ich mache mal hier eine Klammer dran, damit wir das besser erkennen.
Also wir wollen Abhängigkeiten auflösen und das wollen wir tun,
indem wir oder das wollen wir tun dazu,
dass wir Tests durchführen können.
Tests bedeuten immer, dass wir schauen können,
was passiert denn eigentlich
Wir führen ein Stück Programm aus. Klar,
er hat mit einem bestimmten Eingabewerten,
aber wir wollen vor allen Dingen schauen, was passiert da.
Und das ist dieses, was wir durchaus als überwachen oder beobachten,
bezeichnen wollen, je nachdem, wie sie, ich finde,
ich kann ihren eigenen Begriff dafür verwenden.
Damit wir das tun können, müssen wir die Sachen auftrennen,
damit wir wirklich diese kleinen Tests durchführen können.
Ja, also was wir erreichen wollen,
ist Beobachtbarkeit des Verhaltens für den Test und wir wollen es
den Testaufwand verringern durch Tests
Wenn Sie sich erinnern an die Qualitätsmerkmale, dort war es Unterwartbarkeit,
gab es den Punkt Testbarkeit, Wartbarkeit war Veränderung wahr.
Aufwand für Veränderungen. Und Testbarkeit war Aufwand für Tests.
Also wir wollen den Aufwand für Tests dadurch bringen,
dass wir diese kleinen Tests haben. Zwar änderten, vorher war das.
Und diese beiden Sachen wollen wir jetzt erreichen. Das ist das,
was wir hier in dem Schritt eben hat,
der wir bis jetzt noch nicht so genau besprochen haben.
Und beide Ziele hängen ganz eng miteinander zusammen,
denn Abhängigkeiten auflösen, dafür gibt es ganz viele Möglichkeiten und Refactoring,
sind letztlich basiert darauf, dass wir Sachen durchaus verschieben.
Und da müssen wir auch Abhängigkeiten aufgelöst haben.
Wie ich möchte hier als Mittel dafür durchvorstellen, Fake-Objekte und Mock-Objekte.
Das ist das, was Sie in den Fragen schon hatte.
Was ist denn so etwas? Ich zeige kurz mal ein Beispiel,
worum es dabei geht. Wir haben hier eine Klasse,
die mit dem Namen Network Bridge und die soll dazu Dati sein,
eine Hardware zu konfigurieren, beziehungsweise diese Konfiguration zu verwalten.
Ja, Endpoint ist der Name der Hardware, die wir dazu haben.
Und Endpoint öffnet dazu einen Socket. Ja, wir haben ein Gerät,
was wirklich eine Kommunikation hatte und das auf der Flugsystem-Ebene ist das
häufig über Sockets und für den Netzwerkverkehr, den wir eigentlich brauchen,
ist eigentlich diese Methode vom Routing hier gedacht.
Dieses Beispiel stammt auch aus dem Buch von Veters.
Ich gebe das hier unten immer an. Sie finden ja
in der Literatur den Hinweis dazu, zu dem Buch Michael Fesers.
Wie gesagt, es ist eine sehr schöne Sammlung von Episoden und Fallstudien.
Ich denke, die Struktur ist nicht ganz so schön,
um daraus tatsächlich zu lernen.
Ich hoffe, ich kann Ihnen hier damit Struktur geben.
Die doch scheinen sich durchaus in das Buch rein,
um solche Beispiele im Detail zu besser zu verstehen oder noch
zahlreiche weitere Episoden und Beispiele da zu finden.
Was wir hier brauchen, wenn wir diese Klasse Network Bridge testen wollen, ja,
dann müssen wir es erreichen, dass Hardware-Komponenten halt abgetrennt werden.
Sonst kriegen wir keinen Juni-Test hin, der klein und begrengen Aufwand durchzuführen ist.
Es muss uns gelingen, andere Netzwerkpartner loszuwerden.
Das will ich erst die alle aufsetzen müssen,
die müssen einen bestimmten Zustand haben, den Windtest durchführen können
Und wir müssen es schaffen, dass wir den Netzwerkverkehr tatsächlich passiert,
irgendwie simulieren, statt ihnen wirklich zu überwachen.
Und das wollen wir tun, indem wir die Beteiligten,
die Kollaborateure, also wie die mit uns zusammenarbeiten, simulieren.
Und dazu die Begriffe Fake-Objekt und Mog-Objekt.
Hier auf der Folie zunächst erstmal Fake-Objekt, was das ist.
Wir ersetzen den Kollaborateur durch etwas anderes.
Wir ersetzen ihn durch etwas, was gut diese beiden Eigenschaften
trennen und beobachten
Und das benutzen wir nur für den Test.
Und wir nutzen das, um Abhängigkeiten aufzulösen.
Ich möchte, dass es einem kleinen Beispiel machen,
was ebenfalls aus dem Buch von Fehlpass stammt. Dieses,
hat mir dieses Beispiel, nutzt ein Kassensystem als ein klassisches System,
wo wir sagt, wir haben sogar eine Menge Software,
aber sehr stark mit Hardware verbunden.
Sie kennen diese Kassen, die heutzutage überall stehen.
Man hat nicht mehr Tasten, sondern man hat dann auch noch vorm einen Bildschirm.
Meistens ist das in der Art Touchscreen. Nur denkst du,
war die Tastatur ganz weggelassen, dass sich auch die Tasten darauf habe,
parallel dazu oder zusätzlich habe ich einen Drucker,
vielleicht noch ein kleines Terminal,
so eine kleine digitale Anzeige für irgendwas anderes,
die Waage oder das mit dem Kunden den Betrag zeigt oder was.
Und natürlich irgendwie Hardware und der Scanner. Und wir wollen jetzt in diesem System,
in diesem Umfeld etwas testen, und zwar das,
was wir testen wollen, ist die Klasse. Sale,
die den eigentlichen Einkauf, vor den eigentlichen Verkauf eines Artikels abwickelt,
indem sie den per Scanner, per Barcode, ist der Scanner,
liest den Barcode, liefert aus der Datenbank den tatsächlichen Artikeldaten,
also den Namen für dieses, ich brauche ja eigentlich nur den Preis,
aber für diesen Kassenbong brauche ich auch noch den Namen.
Also das wird da geliefert und das kann ich dann,
das liefert diese Methode. So und ihr in unserem System,
in unserem Beispiel sei das mal so,
dass das tatsächlich für ein bestimmtes Display hier die konkreten Daten liefert.
Und was wir jetzt, was die Klasse sehe,
wirklich macht oder wenn wir die Klasse Segel testen wollen,
zum Beispiel nach einer Änderung oder nach einem Reflektoring oder für eine funktionale Erweiterung,
ist, ob das Display,
also dieses Ding hier,
das Richtige anzeigt
Soweit ganz gewöhnlich. Dann sollte ich denken, ist nicht weiter schwierig.
Das Problem ist nur, die Entwickler haben immer beim Entwickeln
der Klasse Seele sehr stark Bezug genommen auf dieses Display.
Das heißt, die Anstellung der Elektronik, der Anstörung der Pixel,
das ist auf eine Zeile, welche Schriftgröße, irgendwas,
das steckt tief überall in dieser Seelenleister drin.
Und jetzt müsste man eigentlich,
da müsste man beim Test immer jemanden hinstellen und sagen,
okay, das, was zeigt denn das Display wirklich an?
Man könnte sich dadurch helfen, dass man eine Kamera hinstellt,
Bilderkennen und so weiter
Was wir tun wollen, ist, dass wir das Display
durch etwas ersetzen, was wir softwaretechnisch beobachten können.
Ja, der Begriff trennen und beobachten über Überwachung und Trennung,
den wir hier hatten. Dieses Überwachen wollen wir eben
per Software hinbekommen, damit wir einen Unit-Test machen können.
Ja, und wir wollen damit der Zugriff, der Testpunkt,
den wir ein paar vor dem vorher hatten.
Ja, der Testpunkt wäre jetzt der Zeitpunkt,
wo wir das Display aktualisieren. Nach dem Scan-Vorgang will ich
auf dem Display was Neues anfangen und ein neues darstellen.
Wenn ich mir das abgreife, was dargestellt werden soll,
dann habe ich ja den Wert, der das Display auch anzeigt.
Da muss ich da keinen Menschen hinsetzen und keine digitale Kamera
So, also das ist der Punkt zum Beobachten,
zum Überwachen. Wir schauen uns das im Beispiel an.
Also zunächst versuchen wir, wir machen also genau das,
was wir eben auf der Folie hatten, trennen und beobachten.
Zunächst wollen wir mal zum, erst mal das Trennen des
Hardware-spezifischen Teils machen. Klassisch sieht das so aus,
dass die Klasse Clay Sale einen Bezug hat auf eine andere Klasse,
nämlich das R56 Display.
Und wir liefern, wir rufen dort eine Methode auf Showline.
Ja, diese Showline zeigt vielleicht hier auf dem Ding
eine Zeit
Und das wäre ja eigentlich genau der Punkt, wo wir
uns abgreifen können, okay, was zeigt denn das Ding?
Und deswegen machen wir das so, dass wir,
das verhindert mir ja auch schon mal so ein Beispiel,
dass wir statt der wirklichen Klasse oder eine Exemplar dieser Klasse,
dass wir hier ein Exemplar eines Interfaces nehmen,
für eine Inzenzierung dessen.
Das heißt, wir rufen auch nicht ein Showline dieser Klasse
Display auf, sondern wir rufen Showline eines Interfaces Display auf
Und dieses Interpace-Display hat dann, ist dann eigentlich nur die Schnittstelle,
dass tatsächlich tatsächlich in Display klasse, das heißt,
wenn wir eine Instanz verwenden, im realen Fall,
wirken wir hier diese Instanz haben,
die Funktion ist dann ganz genau die gleiche.
Für den Test ist es jedoch möglich,
das sehe ich stattdessen hier eine andere, eine Ersatzklasse nehmen,
diesen simulanischen, diszipulierten Kollaborateur. Und der macht genau das,
was wir brauchen, um diese letzte Nachricht zu Showline,
was Showline als Parameter bekommen hat, zu uns darzustellen.
Und deswegen stellt er das nicht elektronisch dar,
sondern er packt es in ein Feld, in ein Attribut, in eine Variable.
Und er speit, also dieses richtige Display packt es in die Leuchtpunkte.
Und dieses Fake Display packt es in eine Variable.
Und dann können wir es abrufen und können prüfen,
ist denn das Richtige dargestellt worden?
Dazu hat sie natürlich erstmal, hat dieses Fake-Objekt,
hat erstmal diese Methode Showline. Die brauchen wir ja,
weil die rufen wir hier auf.
Damit, dass es hier zu diesem Interface passt.
Und das ist genau das, was hier auch passiert.
Insofern spielt sie also genauso mit in der Kollaboration, wie echte Klasse.
Aber wir haben zusätzlich noch eine weitere, also das ist das,
was wir von sehr benutzt wurden, diese Showline.
Und wir haben hier noch eine weitere Operation, eine Methode,
die genutzt werden kann, um diese Beobachtbarkeit hinzukriegen,
die wir eben hatten, trennen und beobachten.
Also das Trennen passiert über das Interface,
das Beobachten hier, indem wir eine Variable haben,
die den letzten Wert hält und eine Operation,
eine Methode, die auf diesen letzten Wert zugreift.
Damit haben wir die Möglichkeit, diesen einen automatisierten,
einen Test zu machen,
ohne dass wir hier noch jemand hinsetzen müssen,
der das Ding hier anschaut und ohne dass es die
überhaupt haben müssen
Ich möchte Ihnen für das Beispiel natürlich auch den wirklichen Code
nicht vorenthalten. Der stand wieder auch aus dem Federsbook-Buch.
Also hier haben wir die Klasse Fake Display, die hat diese,
das Airtribut Last Line, was zu Anfang leer ist.
Und der Showline macht nichts weiter. Er packt es nicht zu Leuchtpumpen,
sondern übergibt das nicht zu Leuchtpumpen, die Elektronik tut etwas,
sondern es speichert nur diesen Wert für späteres Ausprobieren.
Ja, und dieses Get Last Line ist natürlich nur
der Zugriff darauf.
Das heißt total simpel
Und das Showlight ersetzt das, was sonst die Elektronik gemacht hat,
nämlich steuere Bildpunkte einbringe, die zu leuchten.
So, und ihr, wenn wir dann den Testanisch dazu haben, was passiert denn hier? Ja,
wir haben also eine Klasse, die den Aufruf macht,
ja, und diese Klasse hat hier ein Display und da nehmen wir ein Fake-Display,
statt dem echten Display, aber wir rufen die Methode Display auf,
ja, und wenn wir zum Beispiel ein Tal einzuscannen.
Natürlich ist das Sparcode ein bisschen länger. Dann kommt zum
Beispiel, wo können wir das Geld Last Line ausprobieren?
Und wir sollten dann aus der Datenbank den Wert Milch 3 Dollar 99 zurückbekommen.
Wenn das denn gut funktioniert. Und wir brauchen dazu keinen
Fotosdisplay zu setzen. Und wir brauchen das Display nichts.
Also das ist jetzt hier der testhanisch. Hier sehen wir die Methode,
die beiden Methoden, die hier wirklich beim Test aufgerufen werden.
Scannen, um den Wert aus der Datenbank zu rufen
und wird Last Line, um dann zu schauen,
welcher Wert ist denn gekommen
Soweit zu Fake-Objekt. In Fällen,
wo ich viele Objekte brauche, um etwas zu testen,
gibt es noch eine erweiterte Form des Fake-Objekts und das ist das Morg-Objekt.
Wenn wir das Fake-Objekt enthält,
ja eigentlich nur die Simulation des Beteiligten des Kollaborateurs,
so hieß es hier zwei Folien vorherein.
Wo war es hier? Ja,
sieben Ersatz für den Kollaborateur einer Klasse
Das Mog-Objekt kann näher, das Mog-Objekt enthält auch noch zusätzlich
die Überwachung, die Auswertung mit dabei.
Es enthält den Aufruf und die Prüfung der Ergebnisse mit dabei.
Das heißt, es ist ein ganzes Stück des Testhannish hiermit integriert.
Hier in unserem Beispiel haben wir quasi das Gleiche,
was wir eben schon gesehen haben. Also wir haben hier,
wir haben es hier mal einen anderen Namen gegeben, Mog-Display,
nicht Fake-Display und dieses Mog-Display hat selber versteht selber die ganzen Methoden,
die es hier und prüft dir gleich, mach den Aufruf, prüf das gleich.
Und stell da, ob es wirklich das Richtige war.
Und für diese Mock-Objekte, die sind ja wirklich etwas,
was vorgefertigt werden kann für bestimmte Dinge,
vielleicht nicht gerade für so ein digitales Display,
aber für viele andere Sachen kann ich so ein Lock-Objekt vorfertigen.
Und das kann ich dann nur noch an,
brauche ich dann nur noch anpassen.
Und deswegen gibt es für Mock-Objekte umfangreiche Bibliotheken,
auf die man benutzen kann beim Programmieren.
Das gehört Testautomatisierung nur traditionell für den Bereich,
wo man auch gern bereit ist als Entwickler oder als Firma,
Geld für zu bezahlen
Das sind jetzt die Punkte Fake- und Mock-Objekte.
Wir gehen zu den Fragen, nochmal zu schauen,
das war hier die Frage, 1920,
was ist ein Fake-Objekt,
was ist ein Mock-Objekt