Als nächstes sprechen wir über Teststrategien, das ist der Abschnitt 6-
3. Und auch bei den Teststrategien geht es vorrangig um das Risiko.
Wir haben hier als Fragen, die Frage 5,
die uns, die auch sich wieder auf das Buch bezieht,
von dem Maya und die Kass.
Und wir wollen letztlich die Risiken,
die hier in der Frage angesprochen werden, sind letztlich Risiken,
die damit zusammenhängen, dass wir,
dass das Projekt scheitern könnte,
die gleichen Risiken,
die wir bei Migration
auch schon hatten
Wir haben zunächst erst mal als Übersicht, starten wir wieder
mit einem solchen Bild, was die verschiedenen Strategien auflistet.
Wir gehen hier auch auf die zentralen ein.
Aber am Ende werden sie merken, es sind Sachen,
die wir in dieser Veranstaltung schon besprochen haben.
Wir beginnen mal mit dem ersten,
hier oben 6-1, Right Tests,
Incrementaly und bei der Gelegenheit analysieren wir,
welche Risiken am Ende hier
eine Rolle spielen
Risiken, die durch Tess verringert werden, das sind die Risiken,
dass man am Ende durch das Verhalten,
durch Fehler gestört wird,
also Fehlverhalten
Das ist letztlich, er hat gar nicht unbedingt etwas damit zu tun,
dass man Re-Engineering oder Refactoring macht, sondern das ist ja immer,
wenn wir es auf der Änderung durchführen.
Aber noch wesentlicher ist eigentlich, dass wir die Fähigkeit für
Evolutionen verlieren, indem wir die Wartbarkeit verringern.
Und das müssen wir durch Refactoring weiter erhalten. Wo er
auf Wartungsaufwand durch Ausbleibendes Refactoring ist das Risiko und ich schreibe mal gleich,
damit wir wissen, in welche Richtung das geht,
die Lösung mit dazu.
Sicherheit für Refactoring
durch Tests schaffen
Das ist ein weiteres Risiko, dann das nächste Risiko ist.
Die unbekannte, das unbekannte Verhalten. Das dazu führt,
dass wir fehlerhafte Dinge beim Refactoring oder bei Änderungen
vornehmen und hier auch gleich die Lösung,
dass wir Fettes einführen,
die wir für dir
für schönen Begriff Charakterisierungstests hatten
Zur Ermittlung und Umschreibung des Verhaltens. So,
und das sind eigentlich so die wesentlichen Punkte,
die wir jetzt in diesen Dingen haben werden.
Und jetzt schauen wir uns nochmal die Dinge anfangen. Zunächst,
dass man mit einem mit 6-1,
wie schon gerade gesagt,
diese Tests sind jetzt genau das,
was wir brauchen,
um Reflektring zu unterstützen
Nein, das wollten wir anders sehen, wir werden andersrum gemacht,
die irgendwo mal hinten dran, machen wir hier auch so.
Nicht du, enablen, überwünschen. Diese Nummer bezieht sich jetzt,
wie schon gesagt, beim letzten Abschnitt schon gesagt,
auf die, auf die Kapitel dieses Buches.
So, hier geht es vor allen Dingen darum, Effectoring durch Tests absichern und unterstützen.
Ich hatte bei dem Abschnitt über Tests beim Re-Engineering schon bei Legacy-Systemen schon gesagt,
dass es nicht nur darum geht,
dass wir pro forma für Effectoring-Tests immer brauchen,
sondern es gehört auch dazu,
oder ich hatte den psychologischen Effekt geschildert,
den es in meiner Erfahrung auch für die Entwickler hat,
wenn sie einfach wissen,
das sind Unitests da
Dann traut man sich überhaupt über so eine Veränderung,
über eine Effektorin, über eine Umstrukturung nachzudenken.
Eine Klasseverkleidung im Dialog vor kleinnern in der Datenbanktabelle zu verlegen,
Komponentgrenzen zu verschieben, Komponenten aufzuteilen.
All das würde man nicht tun, wenn man nicht ganz sicher wäre.
Ich habe hier Tests wie mein Verhalten absichern. Am Ende,
wenn ich der bin, der eine Woche Verzögerung verursacht,
weil plötzlich alles nicht mehr geht,
20 Leute in meiner Entwicklermannschaft plötzlich überall an nichts tun können,
weil alles nicht mehr geht,
dann würde ich ganz schön dumm dastehen von meinem Chef und vor meinem Auftraggeber.
Und deswegen würden sie das nicht tun.
Wenn sie aber am nächsten Morgen gleich merken, oh,
es funktioniert alles, sonst machen sie einfach wieder zurück,
dann würden sie sich sowas dran nehmen.
Also dieses Absichern und Unterstützen, ich meinte jetzt vor
allen Dingen dieses Unterstützen mit als mentale Unterstützung.
Wir hatten diesen Begriff genannt Cover and Motify statt Edit und Grey.
Das ist ein Bezug zu dem Kapitel 4.
Also das ist der wesentliche Punkt, den wir hier haben
Das ist der wesentliche Punkt bei 6-1, den ich jetzt hervorheben möchte.
Ich schreibe jetzt nicht ganz so viel, wie wir bei
den letzten Dingen haben. Dann zum Abschnitt 6-2,
zu dem Strategietrist 6-2, Growyour-Test-Base, Incrementaly,
bedeutet einfach nur, wir sollten versuchen,
nicht das auf einmal zu erwarten,
dass wir es auf einmal ganz viele automatisierte Tests haben.
Wir machen drei Monate lang nichts anderes als Tests bauen.
Nein, bei jeder kleinen Veränderung,
bei jedem Reflektoren fügen wir etwas zur Testbasis hinzu
Das ist eine neue Seite. Das ist deswegen überhaupt realistischer
, wenn wir das implementell machen. So, also das
Aufstellen kulturellisierter. Ich schreibe mal lieber automatisierbar werden.
Das ist aufwendig. Wir sollten das nach und nach machen,
wenn alles andere ist nicht realistisch. Mit jeder Veränderung,
mit jedem Refectoring Das Erstellen, nie einen Test machen,
ohne noch zusätzlicher in die einen Refectoring oder eine Veränderung machen,
ohne zusätzliche Tests zu erstellen.
Soweit dazu in. Wir haben, jetzt gehe ich mal
gleich weiter im User-Testing-Framework, würde ich gar nicht viel dazu sagen.
Der Punkt 6-3 hier,
weil das ist eigentlich klar, wir sollten versuchen,
so viele Tools zu benutzen,
wie irgendwie möglich,
zu dem Punkt hier unten
6-4 Tests, The Interface, not the implementation,
hängt ein bisschen, ich hatte das schon erwähnt, bei Charakterisierungstests.
Wir haben die Tendenz in der Whitebox-Tests erstellen.
Und das ist ja das, was wir bei Charakterisierungstests machen,
dass wir dann auch Sachen in den Tests hineinbeziehen,
was wirklich ein Implementierungsdetail ist, was sich vielleicht später ändern kann.
Diese Entscheidung, was ist jetzt Implementation und was ist Interface
, ist ganz schwer bei Legacy-Systeme.
Ich schreibe das mal trotzdem mit als Punkt auf
Tests in the face not the implementation. Schön, das ist 6-4.
Bei Erstellung von Charakterisierungstests Veränderliche Implementierungsdetails Nicht einbeziehen bzw. ignorieren,
wenn sie wollen, wobei das schwierig ist,
nur ein bisschen besser gerissen, wobei das schwierig ist,
Schwierige Entscheidung, weil Interface, das Interface ist nicht spezifiziert.
Meistens nicht. Wenn wir eine tolle Beschreibung hätten,
wir seien bei Contract-mäßig Vorbedingungen, Nachbedingungen, dann wäre es einfach.
Aber meistens haben wir ja nicht mal ein Modul,
sondern wir schaffen das Modul ja durch Refactoring.
Und da müssen wir entscheiden, was gehört jetzt zu
dieser Leistung, die wir diesem Modul zuerkennen.
Und daraushin könnte man auch sagen, okay,
das und das sind dann Implementierungsdetails,
die werde ich vielleicht bei der nächsten Endung
dann ändern
Und das Ziel dabei ist bei diesem Interface-Testen ist ja,
dass wir bei Implementierungsänderungen kein...
Ich nenne es mal bei Optimierung der Implementation
So, das war, das war der Punkt 6.4.
Der Punkt, wir haben ja noch weitere 6.5 Record
Business Wouls, Tests. Das ist eine Empfehlung,
die eigentlich den Veränderungsprozess mehr betrifft als den Record Buctoring Bucts Prozess.
Wenn wir nämlich vom Auftraggeber Empfehlungen bekommen,
das und das soll jetzt eine Geschäftsregel optimiert werden,
sollten wir gleich versuchen, diese Geschäftsregel gleich als Test zu formulieren.
Das wird uns, das hilft uns,
wenn wir später vielleicht doch mal zu einer Ablesung des Systems
kommen müssen,
dann haben wir Beschreibungen der Geschäftsregel
Diese Geschäftsregelbeschreibung gibt es meistens nicht in so einer Form.
Und deswegen ist das hier, nennt sich Dir der Punkt.
So, das sollten wir hier vielleicht auch mit aufschreiben.
Und deswegen brauchen wir noch eine neue Seite.
Das ist die Musik
Wir haben ein funktionaler Veränderung, also ich betone jetzt,
es geht jetzt nicht so stark um Refactoring-Veränderungen.
Das, was man klassischerweise als Martin oder als Change-Request für
Sharing Change Request
noch mit dahinter bezeichnet
Das sind Dinge, die wir hier brauchen,
die wir ganz häufig während des normalen Ablaufs haben