Nachdem wir im ersten Teil besprochen haben,
was dieses Edit und Bray und Cover und Modify denn bedeutet,
wollen wir jetzt drüber sprechen, Cover ummanteln, worin das besteht.
Wir sehen schon hier die nächste Frage, Testharnisch,
das ist auch das sprachliche Bild, was Michael Fielders wählt,
um das zu zeigen, das ist hier auf dieser Folie dargestellt,
worum geht es dabei? Und man den Harnisch ist,
das ist die Ritterrüstung, das ist das,
was uns stark macht und dass es dieses Bild hat,
er gewählt, um hier zu zeigen,
dass der Code,
um den es geht,
der geändert werden soll,
vorher in Tests eingeschlossen wird
Warum brauchen wir das? Wir wollen erreichen, dass das übliche Vorgehen,
nämlich anschließend zu testen, durch einen Testfirst ersetzt wird.
Lassen Sie uns das kurz aufschreiben. Das übliche Vorgehen sieht
so aus, und durchaus möchte ich das lobend erwähnen,
wie die Entwickler heute vorgehen, mich das gar nicht irgendwie kritisieren.
Sehr risikobewusst und sehr vorsichtig. Das übliche Vorgehen sieht so aus,
dass man Das ist mein Erst entwickelt,
also erst Änderungen vornimmt und danach testet.
Tests sind häufig, das können wir besser hier machen.
Auf Anwendungsebene vorhanden Zum Beispiel für ganze Use-Cases oder sowas.
Und deswegen hat man lange Feedback schleifen. Lange deswegen,
weil man den Test für einen größeren Bereich macht,
und da muss man eine Weile suchen,
bis man einen möglichen Fehler gefunden hat, macht es entsprechend weniger.
Und man macht das so, dass man Regressionstests durchführt
Vielleicht etwas zum Begriff Regressionstest, Regressionstest meinen,
dass man die Tests immer wiederholt und nach und nach auf
die Sachen konzentriert, die noch fehlerhaft sind. Das heißt,
ich mache zum Beispiel für einen bestimmten Bereich alle Use Cases,
die wir normalerweise testen,
vor einer Freigabe und dann gibt es ein,
findet man ein, zwei,
drei Fehler und da werden nur die Sachen wiederholt,
wo die Fehler auftreten und dann nochmal wieder noch
eine Schleife und noch eine Schleife und noch eine Schleife
Diese Tests sind dadurch gekennzeichnet,
ja, und wir tun diese Tests natürlich unbedingt.
Ja, also das ist das Übliche, das übliche Vorglied.
Diese langen Feedback-Schleifen kommen daher, weil die Tests auf Anwendungsebene sind,
haben wir Die Tests auf Anwendungsehe bedecken einen größeren funktionalen Bereich,
im größeren Bereich des Codes ab.
Oder umfassen den. Und dann zusätzlich haben sie
lange Lauf, längere Laufzeit und lange Vorbereitungszeit
Bist du ihm zu solchen Sachen? Ich muss aus
der Datenbank aufsetzen, die die Testdaten enthält,
um ein bestimmtes Stück Test machen zu können.
Lange Vorbereitung, Laufzeit und dann großer Aufwand für
die Suche.
Nach Fehlern
So, das ist das übliche Vorgehen, was man dabei macht.
Dazu, also dieser Begriff für den Code, für den,
den man dabei schreibt, das bezeichnet man eben als Testhannisch.
Damit ist dieses Ummanteln des Kurs gemeint und das ist der Testcode,
den man braucht, den man braucht, um ein Stück Code zu testen.
Hier haben wir den Begriff Fragment verwendet,
Fragment im Sinne von einfach nur ein Stück.
Das ist nicht wirklich ein Modul. Von Modularität sind wir
häufig im Sinne von guter Entkopplung und hoher innerer Festigkeit,
da sind wir meistens ziemlich weit entfernt.
Also es geht darum, um den Testcode,
um etwas zu prüfen und natürlich noch das, um das zu starten,
die Vorbereitung zu treffen und vielleicht hinterher die Ergebnisse zu veranschaulichen,
zu prüfen.
Ja, man verwendet durchaus solche Frameworks, VJ Unit,
hier um solche Tests durchzuführen. So,
das sind diese langen Tests, Feedback-Schleifen, das ist das,
was wir durchaus als große Tests bezeichnen und was wir
eigentlich erreichen wollen, sind kürzeres Feedback.
Direkteres Feedback und kürzere Laufzeit
So, das wären, das wäre also sozusagen
ihr diese Tests, das sind die sogenannten größeren Tests.
Wer kam das hier in der Frage 13?
Ja, genau, die größeren Tests gegenüber kleineren Tests.
Und das möchte ich gerne hier
Besser wären, wir hatten kleinere Tests.
Diese kleineren Tests sind dadurch gekennzeichnet,
dass wir nur wenig gut abgerechnet betroffen haben
Wenig Abgängigkeiten zur Umgebung. Kleine Foltbereiche. Umfasst,
nehmen wir das mal hier. Und damit haben wir
auch erreicht, dass am Ende die Vorbereitungs- und Ausführungszeit
geringer ist
Und vor allen Dingen, das ist der wesentliche Punkt,
darf die Zeit für die Fehlerlokalisierung ist deutlich geringer.
Das ist das,
was wir erreichen wollen und diese kleinen Tests sind tatsächlich,
würden uns sehr helfen,
aber sie sind schwierig zu erreichen
Das Problem dabei ist, dass wir häufig Abhängigkeiten in die
Umgebung haben. Solche Abhängigkeiten, was meine ich mit solchen
Abhängigkeiten?
Ein Beispiel
Dass wir eine Kommunikation mit einer Datenbank haben. Dass wir
Austausch über ein Netzwerk haben. Dass wir Zugriffe auf ein Dateisystem
haben. Dass wir andere Wechselwirkungen mit der Umbebung haben,
zum Beispiel Sachen, die man als Konfiguration konfigurieren muss
Ich muss also irgendwo Parameter setzen, diese Netzwerksachen wäre auch
so eine Konfiguration, ich muss da irgendwelche Rauter einstellen.
Das sind alles Dinge,
die wir ändern müssen und das sind Sachen,
die verhindern,
dass wir so
einen einfachen Unit-Tests machen
Denn dein Unitest setzt dir voraus, dass ich ganz schnell mal automatisch prüfen kann.
Und das alles sind Schritte, da fördert hier Schritte,
die uns so eine automatische Prüfung nicht machen können.
Und das ist was, wo wir uns schauen müssen,
wie kriegen wir denn das hin?
Ich möchte kurz einem Beispiel vorstellen, was wir meinen,
was man meinen könnte, mit enger Kopplung und Auflösen dieser engen Kopplung.
Hier aus dem Buch von Michael Feders, ein Beispiel,
hier in diesem Beispiel soll, hier geht es darum,
dass wir hier Rechnungen haben, die in einer Datenbank verwaltet werden
Und wir wollen hier Rechnungen aktualisieren, nachverfolgen,
ob sie bezahlt werden. Wie ist der Stand solcher Rechnungen?
Wie viel sind, hat ein Kunde schon bekommen? Sowas,
also es geht um die Verwaltung von fachlichen Objekten,
das hier, was hier die Rechnungen sind.
Und wir nehmen jetzt mal an, wir wollen hier zwei Methoden ändern,
nämlich dieses Get Response Textor, wir können das durchaus hier dranschreiben mal,
noch müssen wir mit Grün.
Ja, also hier dieses Get Response Text,
sei zu ändern und hier Get Value.
Ja, also das sind zwei Sachen, die wir,
wo wir drauf zugreifen wollen.
Und hier umsteht es auch nochmal in dem Kommentar aus dem Bild
Wenn wir das aber machen wollen, ganz klar, ja,
ist ja vielleicht gar nicht so viel Umfang in den Methoden.
Aber das Ganze hängt immer damit ab, davon ab,
dass wir hier eine Kommunikation mit der Datenbank haben.
Wenn wir das auflösen wollen,
muss es uns irgendwie gelingen, diese Datenbankkopplung aufzulösen.
Wir müssen dann irgendwie versuchen, diese Datenbank wegzubekommen.
Also hier muss ich erst, um das aufzusetzen,
muss ich zunächst, das muss man in der Hinterbase Connection übergeben.
Ja, kann ich kein Objekt-Invoice-Update respondern in einem automatisierten Test erstellen.
Und das Gleiche hier, die Invoice kriegt ja
ihren Wert von dort
Das muss uns also dazu gelingen, dieses DB Connection abzutrennen und
durch etwas anderes zu ersetzen, um solche Tests zu haben.
Die nächste Folie zeigt uns, wie eine mögliche Lösung aussehen kann.
Und zwar ist hier das DB Connection dadurch abgetrennt,
dass wir es über ein Interface ansprechen.
Also das Interface liefert, den ermöglicht den Zugriff auf diese Methode,
auf die Operation, die wir hier haben.
Und die tatsächliche DB Connection ist hier die Implementation des Interfaces
und wir könnten für Testzwecke stattdessen ein anderer eine Testklasse hier benutzen,
uns ermöglicht, darauf zuzugreifen.
Also wir müssten dann hier eben einfach als Parameter die Testgasse bei der Initialisierung machen.
Und die würde uns dann die Daten liefern, die wir hier brauchen,
um einen Test zu haben, der nur diesen Bereich abdeckt.
Also das zeigt uns hier, wie könnten wir nochmal das voragende Bild,
wie können wir dieses Data-Based Connection hier loswerden.
Das Problem ist, also ja, es gibt hier sogar,
es gibt ja sogar Reflectorings, die dazu dienen,
Primity Vice, Parameter, Extract Interfaces,
das wären Effectorings,
die wir machen können
Wunderbar, wenn Sie sagen, ja, es gibt ja
sogar Refactorings. Das Problem ist, Refactorings zu machen,
erfordern, Tests zur Absicherung. Aber Tests haben wir ja
gerade nicht. Deswegen machen wir ja die Refakte alles.
Merken Sie was? Das ist so ein Teufelskreis.
Ich brauche das eine, um das andere zu machen.
Dieses klassische Henne-Ei-Problem. Was war er da in dem Fall?
Wir brauchen das eine, um das andere zu machen,
aber das andere für das andere brauchen wir das eine auch.
Das ist der Punkt, wo wir versuchen müssen,
etwas zu ändern.
Wir wollen
diesen Teufelskreis durchbrechen