Praktikum Software-Technik: Extreme Programming

Transkript

1 Praktikum Software-Technik: Extreme Programming Institut für Informatik Prof. Dr. Jens Grabowski M.Sc. Benjamin Zeiss Inhalt 1. Die trügerische Sicherheit des grünen Balkens 2. Quelltextabdeckung beim Testen 3. XP & Akzeptanztest 4. Refactoring 5. Refactoring & XP 6. Refactoring-Katalog 7. Stinkender Quelltext 8. Werkzeugunterstützung 9. Refactoring & Testen 10. Zusammenfassung

2 Die 12 XP-Techniken 1. Die trügerische Sicherheit des grünen Balkens (1/2) Der JUnit-Balken ist grün ist jetzt alles im grünen Bereich? Nicht zwingend: 1. Keine Garantie, dass Test an sich korrekt ist: Bei Test und Implementierung kann der gleiche Denkfehler gemacht werden. Fehler steckt sowohl in Implementierung als auch Test. Bei testgetriebener Entwicklung (bei der Testentwickler und Implementierer ja identisch sind) nicht völlig unwahrscheinlich. 2. Falls testgetriebene Entwicklung halbfertig abgebrochen wird, wird nur ein Teil der Funktionalität getestet und auch nur dieser Teil der Funktionalität überhaupt implementiert. Fehler besteht nicht aus fehlerhaftem, sondern aus fehlendem Quelltext.

3 Die trügerische Sicherheit des grünen Balkens (2/2) Nicht zwingend (Fortsetzung): 3. Es wurden zu wenig Unit-Tests geschrieben, so dass nur ein Teil der Funktionalität überhaupt getestet wird. Der von Tests durchlaufene Teil des Quelltexts ist zwar korrekt, aber Fehler steckt in dem Teil des Quelltexts, der gar nicht von Tests durchlaufen wird. Gegen 1. und 2. helfen nur Paarprogrammierung und Akzeptanztests. Gegen 3. helfen außerdem mehr Tests: wie viel Tests sind genug? Tests sollten dafür sorgen, dass möglichst der gesamte Quelltext durchlaufen wird. 2. Quelltextabdeckung beim Testen Wie viel Testen ist genug? Testfälle sollen möglichst gesamten Quelltext abdecken. 100% Abdeckung in der Praxis nur selten bzw. nur mit unverhältnismäßig hohem Aufwand machbar: Auch bei Testgetriebener Entwicklung sollte defensiv programmiert werden, d.h. man sollte Situationen abfangen, die eigentlich nicht auftreten sollten. Solche Situationen sind durch Tests schwer zu provozieren, z.b.: Out of Memory, um zu Testen, ob Implementierung korrekt mit fehlgeschlagenem new umgeht. No space left on device, um zu Testen, ob Implementierung beim Speichern mit vollem Dateisystem umgehen kann. Welche Quelltextabdeckung ist in der Praxis erstrebenswert?

4 Metriken zur Quelltextabdeckung Viele mögliche Metriken, um Quelltextabdeckung zu messen. Die 3 gebräuchlichsten: Methodenüberdeckung Anweisungsüberdeckung Zweigüberdeckung method1(a,b) Hierfür wird Ablaufgraph eines FALSE a>b Programmes betrachtet: block1 public void method1(int a, b) { if (a > b) { block2; else { block1; if (a >= b) { block3; FALSE a>=b TRUE block2 TRUE block3 Methodenüberdeckung Jede Methode wird mind. einmal aufgerufen. Recht grobe Metrik: 100% Methodenüberdeckung deckt selten den gesamten Quelltext ab. Beispiel: Testfall für 100% Methodenüberdeckung: method1: a=2, b=1 100% Methodenüberdeckung ist ein Muss beim Testen! Zusätzlich sollten aber noch weitere Metriken herangezogen werden... method1(a,b) FALSE block1 a>b a>=b FALSE TRUE block2 TRUE block3

5 Anweisungsüberdeckung Jede Quelltextzeile wird mind. einmal ausgeführt. Deutlich besser als Methodenüberdeckung. 100% Anweisungsüberdeckung impliziert 100% Methodenüberdeckung. Beispiel: method1(a,b) FALSE Testfälle für 100% Anweisungsüberdeckung: method1: a=2, b=1 method2: a=2, b=2 Trotz 100% Anweisungsüberdeckung wird nicht getestet, welche Auswirkung es hat, wenn FALSE-Zweig von a>=b durchlaufen wird. block1 FALSE a>b a>=b TRUE block2 TRUE block3 Zweigüberdeckung Bei jeder Verzweigung werden alle möglichen Zweige mind. einmal durchlaufen. Sinnvollste der 3 Metriken. Berücksichtigt auch leere Zweige. 100% Verzweigungsüberdeckung impliziert 100% Anweisungsüberdeckung. Beispiel: Testfälle für 100% Zweigüberdeckung: method1: a=2, b=1 method2: a=1, b=2 method1(a,b) FALSE Ca. 85% Zweigüberdeckung beim Testen! block1 a>b a>=b FALSE TRUE block2 TRUE block3

6 Bestimmung der Überdeckung Quelltextinstrumentierung: 1. Zähler werden an Verzweigungen eingefügt und der derart instrumentierte Quelltext übersetzt. Mögliche Alternativen zur Instrumentierung von Java-Quelltext: Bytecode wird instrumentiert. Java Virtual Machine Profiling Schnittstelle wird abgefragt. 2. Instrumentiertes Programm wird ausgeführt (z.b. durch Start der Unit-Tests). 3. Nach dem Testlauf werden Zähler ausgelesen und die Werte für die gewünschte Metrik berechnet. Üblicherweise wird von Werkzeugen die Abdeckung des Quelltextes inkl. der JUnit-Testfälle bestimmt, da es sich hierbei ja ebenfalls um Java-Code handelt. test-packages sollten bei der Auswertung der Überdeckung nicht betrachtet werden. Code Coverage Werkzeug Werkzeug zur Java-Quelltextinstrumentierung und zur Berechnung von Überdeckungs-Metriken. Tools: Clover (kommerziell), EclEMMA (EPL), CodeCover (EPL) Bild: Clover Praktikum: EclEMMA Weitere Quelltext- Metriken Lines of Code (LOC) ohne Kommentar- & Leerzeilen Methodenüberdeckung: 100% anstreben! Methoden- & Bedingungsüberdeckung Mittelwert der 3 Überdeckungs- Metriken: 85% anstreben!

7 3. XP & Akzeptanztest Unit-Tests bieten keine Garantie, dass Produkt fehlerfrei & vollständig ist. Außerdem testen Unit-Tests nur einzelne Klassen und nicht das Zusammenspiel aller Klassen. XP sieht daher zusätzlich funktionale Akzeptanztests (=Systemtests) vor. Gesamtsystem (aktuelles Release) wird über Benutzerschnittstelle getestet. Anhand der Akzeptanztests kann Kunde sehen, dass seine Funktionalität realisiert ist. Akzeptanztest (1/2) Testgegenstand: System (SUT=System under Test) Test über die Schnittstellen zum Benutzer bzw. zu externen Systemen. Nicht immer zu 100% automatisierbar. Z.B. automatisierter Test der Druckerausgabe schwierig. Relativ gut jedoch z.b. GUI-Tests (Capture/Replay) Jedoch wartungsintensiv, wenn sich UI während der Entwicklung ändert. Quelltextabdeckung ist beim Systemtest i.d.r. geringer als beim Unit-Test, da sich bestimmte Ablaufpfade noch schwerer als beim Unit-Test erzwingen lassen. Akzeptanztest kümmern sich um Standard -Szenarien des Kunden. Überdeckung ergibt sich aus Szenarien des Kunden. Unit-Tests kümmern sich außerdem um Sonderfälle. Hohe Überdeckung beim Unit-Test wichtig.

8 Akzeptanztest (2/2) Basierend auf User-Stories (d.h. Funktionalität): Beschreiben Anforderungen an das Gesamt-System. Zum Ende eines Release-Zyklus müssen alle bis dahin implementierten User-Stories die zugehörigen Akzeptanztests bestehen. Kunde ist i.d.r. nicht in der Lage, selber Akzeptanztests zu schreiben. Entwickler schreiben zusammen mit Kunden Akzeptanztests. Test First vs. Code First: Falls Akzeptanztests vor der Implementierung geschrieben werden, gibt Kunde Benutzeroberfläche genau vor. (Capture/Replay funktioniert nicht.) Falls Akzeptanztests nach Implementierung geschrieben werden, geben Entwickler Benutzeroberfläche vor. Werkzeuge für Akzeptanztests Testen von textbasierten Oberflächen: Z.B. DejaGNU Testen von graphischen Oberflächen: Z.B. Abbot/Costello (open source), IBM Rational Functional Tester (kommerziell), SWTBot (open source) Abstraktere Beschreibung von lediglich Benutzereingaben und erwarteten Ausgaben, die unabhängig von der konkreten Oberfläche ist: Framework for Integrated Test (FIT) Spezielle Java-Klassen, dienen als Adapter zwischen den abstrakten Ein- /Ausgabedaten und der konkreten Oberfläche. Anwender liefert lediglich die Daten, Entwickler kümmern sich darum, wie die Daten in bzw. aus dem System kommen.

9 4. Refactoring (1/3) Def.: Systematische Umstrukturierung von Quelltext, ohne das Verhalten nach außen zu verändern. Ziel: Besser lesbar, verständlicher, Besseres Design, Besser änderbar. Manche Refactorings sind trivial und werden intuitiv verwendet, ohne sich bewusst zu sein, dass es sich dabei um Refactoring handelt. Aufräumen von Code V-17 Extract Method Refactoring (2/3) Beispiel (Refactoring: Extract Method) void printowing() { printbanner(); //print details System.out.println ("name: " + thename); System.out.println ("amount:" + theamount); Extract Method: Extrahieren & in eigene Methode packen void printowing() { printbanner(); printdetails(); void printdetails() { System.out.println ("name: " + thename); System.out.println ("amount:" + theamount); Vorteile: printowing wird übersichtlicher. Neue Methode kann auch an anderer Stelle aufgerufen werden. Macht bei sinnvollen Methodennamen Kommentar unnötig. V-18

10 Refactoring (3/3) Unterschied zu intuitivem Aufräumen von Code : Refactorings beinhalten Systematik anhand von checklisten-artigen festen Schritten zur Quelltexttransformation (Mechanik). Wahrscheinlichkeit, Fehler zu machen (=Verhalten zu ändern) minimieren. Zusätzlich zu systematischen Schritten: Tests geben Sicherheit, dass Verhalten nicht geändert wurde. Falls von Refactoring betroffene Klasse(n) nicht von Tests abgedeckt sind: vorher entsprechende Tests schreiben. Während des Refactorings soll nicht noch zusätzlich neue Funktionalität hinzugefügt werden. Entweder: Refactoring Oder: Neue Funktionalität hinzufügen V Refactoring und XP (1/2) Warum ist Refactoring für XP wichtig? XP sieht einfaches Design vor: Einfache Lösung kann jedoch für neue Funktionalität zu einfach geworden sei. Refactoring hilft dann weiter! Erinnerung: Einfaches Design beinhaltet auch: Keine falschen/unbewiesenen Annahmen über Zukunft, auch nicht bzgl. Performance: Refactoring auch auf Kosten der Performance! Make it run, make it right, make it fast! : Performance-Tuning erst am Ende! Flaschenhälse liegen oft sowieso an Stellen, wo man es nicht vermutet und diese können sich mit der Zeit auch noch ändern. V-20

11 Refactoring und XP (2/2) Zwei Hüte, die sich abwechseln: Refactoring Was will ich umstrukturieren? Gibt es einen Test? Test schreiben! Refactoring durchführen Testen Evtl. Fehler beheben Funktionalität hinzufügen Was will ich hinzufügen? Test schreiben Funktionalität hinzufügen Testen Evtl. Fehler beheben Der Versuch, beides gleichzeitig zu tun, geht schief! Der Versuch, zwei verschiedene Refactorings gleichzeitig durchzuführen ebenfalls! Immer separat in die Versionsverwaltung comitten! V-21 Literatur Buch: M. Fowler: Refactoring, Addison-Wesley, 2000 DAS Standardwerk zum Thema Refactoring. Für s Praktikum sollte die Web-Seite (s.u.) reichen. R. Roock/M. Lippert: Refactorings in großen SW-Projekten, dpunkt, 2004 Ergänzende Literatur. Web: Enthält Refactorings wie im Buch, jedoch ohne Checkliste für die einzelnen Teilschritte. Wiki Wiki zu Refactoring V-22

12 6. Refactoring-Katalog Lexikonartige Sammlung von Refactorings Auswendiglernen sinnlos, aber man sollte einmal alle gesehen haben, damit man weiß, dass man bzgl. eines bestimmten Refactorings nachschlagen sollte. In dieser Vorlesung & Praktikum: nur Vorstellung einiger, wesentlicher Refactorings Im folgenden: Refactoring-Name (fett), SituationAbhilfe Code Vorher/Nachher (alte, vom Refactoring betroffene Codezeilen rot, neue grün) Systematische Schritte Vor jedem Refactoring: Sicherstellen, dass Test existiert! V-23 Rename Method Der Name einer Methode erklärt nicht deren Funktionalität. Methodenname passend umbenennen. String gettelephonenumber() { return (theofficeareacode+"/"+theofficenumber); System.out.print(getTelephoneNumber()); String getofficetelephonenumber() { return (theofficeareacode+"/"+theofficenumber); System.out.print(getOfficeTelephoneNumber()); V-24

13 Rename Method: Schritte 1. Vererbungshierarchie beachten: Ggf. gleiche Schritte für Ober- und Unterklassen durchführen. 2. Neue Methode mit neuem Namen deklarieren und Rumpf der alten Methode dorthin kopieren. 3. Compilieren 4. Den Rumpf der alten Methode derart ändern, dass dort nur noch die Methode mit dem neuen Namen aufgerufen wird. 5. Compilieren und Testen 6. Alle Aufrufe der alten Methode durch Aufruf der neuen Methode ersetzen. Nach jeder Ersetzung: Compilieren und Testen! 7. Alte Methode komplett löschen. 8. Compilieren und Testen! So merkt man, falls man in Schritt 6 einen Aufruf übersehen hat. Beachte: kopieren, nicht verschieben! Um sicherzustellen, dass man in Schritt 2 nicht bereits einen Fehler gemacht hat. Wenn bereits das schief läuft, hat man z.b. den alten Rumpf falsch in die neue Methode kopiert. So merkt man sofort, wenn man einen Fehler gemacht hat. V-25 Einschub: Warum so kompliziert? Reicht nicht auch: 1. Methode umbenennen. 2. Compilieren. 3. Jeden vom Compiler als Fehler gemeldeten Aufruf einer nicht-definierten Methode durch Aufruf der neuen Methode ersetzen. 4. Solange Compiler meckert: GOTO 2 Leider: nein! Bei Vererbung nimmt der Compiler die Methode aus der Oberklasse und ist glücklich. Metaklassen-Verwendung (Java: Reflection) und bedingte Compilierung (C/C++: #ifdef) können dazu führen, dass nicht alle Aufrufe vom Compiler erfasst werden. Die Checkliste auf der vorherigen Seite entschärft diese Gefahr. Auch bei der dortigen Checkliste besteht natürlich die Problematik, dass die Compilerläufe Metaklassen und bedingte Übersetzung nicht erfassen, ein Mensch genauso kurzsichtig wie ein Compiler arbeitet. V-26

14 Extract Method Code-Fragment, das zusammenhängt. Durch Methode mit aussagekräftigem Namen ersetzen. void printowing() { double outstanding=getoutstanding(); printbanner(); //print details System.out.println ("name: " + thename); System.out.println ("amount:" + outstanding); void printowing() { printbanner(); printdetails(getoutstanding()); void printdetails (double outstanding) { System.out.println ("name: " + thename); System.out.println ("amount:" + outstanding); V-27 Extract Method: Schritte 1. Neue Methode anlegen und sinnvoll benennen. 2. Extrahierten Code in neue Methode kopieren. 3. Im kopierten Code nach Variablen suchen, die in der Ursprungsmethode lokal sind. Variablen, die nur noch in neuer Methode benutzt werden: Lokale Variable nur noch in neuer Methode Variablen, die in neuer Methode verändert und deren Wert in Ursprungsmethode später wieder benutzt wird: Rückgabeparameter der neuen Methode (return ) Mehr als eine solche Variable: Extract Method geht so nicht! Variablen, die in neuer Methode nur gelesen werden: Als Parameter der neuen Methode übergeben 4. Compilieren 5. In Ursprungsmethode: extrahierten Code durch Aufruf der neuen Methode ersetzen, Deklaration nicht mehr benötigter lokaler Variablen löschen. 6. Compilieren und Testen! V-28

15 Inline Method Code einer Methode ist genauso aussagekräftig wie Methoden-Name. Methoden-Code an Aufrufstelle ( inline ) direkt einsetzen. int getrating() { if (morethanfivelatedeliveries()) return 2; else return 1; boolean morethanfivelatedeliveries() { return thenumberoflatedeliveries > 5; int getrating() { if (thenumberoflatedeliveries > 5) return 2; else return 1; V-29 Inline Method: Schritte 1. Sicherstellen, dass Methode nicht in einer Vererbungshierarchie für Polymorphie benötigt wird (Indikator hierfür: Methode wird in Unterklasse re-definiert). 2. Alle Methodenaufrufe suchen und durch Methodenrumpf ersetzen. 3. Compilieren und Testen! 4. Methodefinition löschen Anmerkungen: Gegenteil von Extract Method Kein Widerspruch: alles was Code lesbarer macht, ist erlaubt! Funktioniert z.b. nicht für rekursive Methoden V-30

16 Replace Temp with Query Temporäre Variable wird nur einmal mit Zwischenergebnis belegt. Zwischenergebnis-Berechnung in Methode packen und diese aufrufen. double baseprice = thequantity * theitemprice; if (thequantity > 1000) return baseprice * 0.95; else return baseprice ; if (thequantity > 1000) return baseprice() * 0.95; else return baseprice() ; double baseprice() { return thequantity * theitemprice; Mehrfache Berechnung erscheint ineffizient, aber: Code wird modularer (und: temporäre Variable gespart) V-31 (Self) Encapsulate Field Direkter Zugriff auf public Attribut von außen (Encapsulate Field) Zugriff auf private Attribut innerhalb derselben Klasse / in Unterklasse soll sich z.b. Wert des private Attributes durch Berechnung ergeben (Self Encapsulate Field) Zugriffsmethoden (get/set) anlegen und Zugriffe durch Methodenaufruf ersetzen. class Person { public String thename; aperson.thename=""; class Person { private String thename; public String getname() { return thename; public void setname(string name) { thename=name; aperson.setname(""); V-32

17 Move Field Ein Attribut wird vorwiegend von einer anderen Klasse genutzt oder passt thematisch besser in andere Klasse. Attribut dorthin verlagern. class AccountType {... class AccountType { private double therate; void setrate(double rate) { therate=rate; double getrate() { return therate;... class Account { private AccountType thetype; private double therate; double ratefordays(int days) { return therate*days/365; class Account { private AccountType thetype; double ratefordays(int days) { return thetype.getrate()*days/365; V-33 Move Method Eine Methode benutzt mehr Methoden/Attribute einer anderen Klasse als aus der eigenen Klasse bzw. wird vorwiegend von anderer Klasse genutzt. Methode dorthin verlagern. class Person { int id; class Project { boolean participates(project p) { Person[] participants; for(int i=0;i<p.participants.length;i++) { if (p.participants[i].id == id) return(true);... if (aperson.participates return(false); (aproject)) class Project { Person[] participants; boolean hasparticipant(person x) { for(int i=0;i<participants.length;i++) { if (participants[i].id == x.id) return(true); return(false); class Person { int id;... if (aproject.hasparticipant (aperson)) V-34

18 Replace Conditional with Polymorphism Fallunterscheidung für unterschiedliches Verhalten in Abhängigkeit von einem Typ. Jeden Zweig der Fallunterscheidung in eine eigene Unterklasse verlagern und diese von gemeinsamer Klasse mit abstrakter Methode erben lassen. class Bird { double getspeed() { switch (thetype) { case AFRICAN: return getbasespeed() / thenumberofcoconuts; case EUROPEAN: return getbasespeed(); class Bird { abstract double getspeed(); class AfricanBird extends Bird { double getspeed() { return getbasespeed() / thenumberofcoconuts; class EuropeanBird extends Bird { double getspeed() { return getbasespeed(); V Stinkender Quelltext Wann Refactoring durchführen? Zeitpunkte: Bevor neue Funktionalität hinzugefügt werden soll: Weil dabei ein Blick auf den Quelltext ergibt, dass er schlecht zu ändern/erweitern ist. Bei der Fehlersuche: Weil man den Quelltext nicht (mehr) versteht. Immer, wenn man eine Funktionalität fertig implementiert hat: Refactoring nicht soweit hinauszögern, bis es weh tut. Das dann nötige große Refactoring ist aufwendiger, als die vielen kleinen, die man vorher problemlos hätte vornehmen können. Indikator, ob Refactoring überhaupt notwendig ist: Stinkender Quelltext ( Code Smells ) V-36

19 Gestank 1: Doppelter Code Doppelter Code ist schlechter zu ändern! Gleicher Quelltext ist mehrfach vorhanden: Extract Method Gleicher Quelltext ist mehrfach in parallelen Unterklassen vorhanden: Pull Up Method (nicht vorgestellt) V-37 Gestank 2: Lange Methode Lange Methoden sind schwierig zu verstehen! Generelle Abhilfe: Extract Method Falls viele temporäre Variablen: Replace Temp with Query V-38

20 Gestank 3: Verteilte Änderungen Eine Änderung betrifft viele Klassen. Zu ändernde Stellen in eine Klasse zusammenziehen: Move Method Move Field V-39 Gestank 4: Neid Eine Methode beschäftigt sich hauptsächlich mit einer anderen Klasse. Methode in andere Klasse schieben: Move Method Evtl. zuvor zu verschiebende Methode verkleinern: Extract Method V-40

21 Gestank 5: Switch-Anweisungen switch wird benutzt, um Typ-abhängig unterschiedliches Verhalten auszuführen. Switch isolieren: Extract Method Isolierte Methode in Oberklasse schieben: Move Method Polymorphie statt switch benutzen: Replace Conditional with Polymorphism V-41 Gestank 6: Kommentare Kommentare sind nicht prinzipiell schlecht, werden jedoch manchmal als Deo benutzt, um anderen Gestank zu überdecken. Statt Kommentar, der erklärt, was die nächsten Zeilen machen: Extract Method Falls extrahierte Methode dennoch einen Kommentar benötigt: Rename Method Falls kein anderer Gestank: Kommentar belassen! V-42

22 Mehr Gestank Für vorgestellte Code Smells kommen häufig noch weitere Refactorings in Frage. Weitere Code Smells bekannt. Beinhalten aber jeweils Refactorings als Abhilfe, die hier nicht vorgestellt wurden. Selber mal im Refactoring -Buch schmökern! V Werkzeugunterstützung Eclipse kann einige Refactorings automatisch durchführen: Codeblock/Bezeichner, der Refactoring unterzogen werden soll, markieren. Im Refactor -Menü das gewünschte Refactoring auswählen. Evtl. Dialog ausfüllen. Eclipse kümmert sich selber darum, dass Punkte der Checkliste abgearbeitet werden. Um Tests muss man sich jedoch selber kümmern. Bei automatisierten Refactorings sind Fehler allerdings unwahrscheinlicher als bei manuellen. Eclipse verwendet teilweise allgemeinere Namen für die Refactorings: Rename kann z.b. auf Methodennamen (=Rename Method) und Variablen (=Rename Variable) angewandt werden V-44

23 Werkzeugunterstützung, um Code-Smells zu erkennen Eclipse Metrics-Plugin berechnet statische Quelltextmetriken. Können bestimmt werden, ohne den Code auszuführen, z.b.: Lines of Code pro Methode, Schachtelungstiefe, Zyklomatische Komplexität nach McCabe. Außerdem existieren Werkzeuge, um nach dupliziertem Quelltext zu suchen. Werden wir in diesem Praktikum nicht einsetzen. Extract Method in Eclipse erkennt duplizierten Quelltext leider nicht. V-45 Zyklomatische Komplexität Von McCabe entworfene Metrik, die geeignet ist, um Spaghetti-Code aufzudecken. Umgangssprachliche Formulierung: Sequentielle Aneinanderreihung von Anweisungen hat die Komplexität 1 Jede Verzweigung oder Schleife erhöht Komplexität um 1 method1(a,b) FALSE block1 Def.: Zykl. Komplexität V für Ablaufgraphen G: V(G)=e-n+p Kante a>=b TRUE e=zahl der Kanten block3 n=zahl der Knoten FALSE p=zahl der Verbindungen nach außen (I.d.R. Single Entry Point, Exit Points entsprechend block4 Anzahl der return-anweisungen) Exitblock4 Point Beispiel: e=7, n=6, p=2. V(G)=3 V-46 a>b Entry- Point Knoten TRUE block2 Kante

24 9. Refactoring & Testen Unit-Tests sichern nicht nur Refactorings ab, Refactorings können es auch erforderlich machen, dass Unit-Tests angepasst werden müssen. Z.B.: Rename Method: Test müssen einbezogen werden. Extract Method: Methode wird erzeugt, für die kein Test existiert. Move Method: Tests für Ursprungsklasse schlagen fehl, Code in Zielklasse bleibt ungetestet. 2 Lösungsmöglichkeiten: Code-First: Erst Refactoring, dann Tests anpassen. Test-First: Erst Tests anpassen, dann Refactoring. Testgetriebenes Refactoring ist vorzuziehen, da Konsequenzen von Refactorings früher deutlich werden. V Zusammenfassung Quelltextabdeckung beim Testen wichtig: 100% Quelltextabdeckung garantiert aber immer noch nicht, dass Quelltext an sich vollständig ist und z.b. alle Sonderfälle abfängt! Refactoring: Systematische Umstrukturierung von Quelltext, ohne das Verhalten nach außen zu verändern. Nur ein Teil der bekannten Refactorings vorgestellt. Refactorings auch für Testfälle benutzen! Ebenso wie für Refactorings gibt es Kataloge mit guten Teil- Designs für Klassenarchitekturen (Entwurfsmuster) Gleicher Nutzen wie bei Refactoring-Katalog: Rad nicht ein zweites Mal erfinden. Gemeinsame Sprache (einheitliche Namen für Muster bzw. Refactoring). Z.B.: E. Gamma et. al. (GOF= Gang of Four ): Entwurfsmuster, Addison-Wesley, 1995 Refactorings können benutzt werden, um auf Entwurfsmuster hin zu arbeiten. V-48