Test-Driven Development Historisch-Kulturwissenschaftliche Informationsverarbeitung Übung: Planung von Softwareprojekten Dozent: Christoph Stollwerk WS 2014/2015 Referent: Dennis Peker

Gliederung Was ist TDD? Ablauf Testen mit xUnit Testbeispiel Warum TDD?

1. Was ist TDD? alternative Entwicklungsmethode von Computerprogrammen erst Test, dann Produktivcode inkrementell Kerntechnik von Extreme Programming, damit Teil der agilen Softwareentwicklung

2. Ablauf Test wird erstellt, der scheitert Pruduktcode wird bearbeitet, damit Test positiv ausfällt Refaktorisieren Erstellen neuer Tests

2. Ablauf Implementierung von neuem Code erst, wenn Test vorliegt zu viel Code lässt nicht getestete Stellen entstehen, die beim Refaktorisieren Fehler erzeugen können Refaktorisierung: Strukturierung des Codes Ziel: Software einfach, redundanzfrei und verständlich machen  Voraussetzung für neuen Test jede Aktivität lässt sich genau einer Phase zuordnen

2. Ablauf Prinzipien: kontinuierliche Designverbesserungen, einfaches Design und Test- First wenn Tests bereits geschrieben sind, ist Code auch testbar höchstsäuberliche strukturierte Codebasis ist erforderlich  Design muss fortlaufend überarbeitet werden  entwickeln, was wir brauchen, wenn wir es brauchen

3. Testen mit xUnit Tests häufig mit xUnit-Framework implementiert grün = bestanden, rot = fehlgeschlagen  Red-Green-Refactor- Zyklus Kent Beck (etablierte TDD in eXtreme Programming): erst neuer Code, wenn Test fehlschlägt Duplikationen müssen entfernt werden (Refaktorisierung)

3. Testen mit xUnit weitere Grundlagen: eng mit Code zusammenarbeiten (develop organically) eigene Tests schreiben Entwicklungsumgebung muss schnell auf kleine Veränderungen reagieren Produkt muss aus zusammenhängenden, jedoch einfach verbundenen Komponenten bestehen, um Testen zu erleichtern

3. Testen mit xUnit Entwickler muss lernen effektive Unit-Tests zu schreiben: schnell ausführbar einzeln ausführbar einfach, verständlich benannt Verwendung „echter“ Daten Tests müssen Entwicklung vorantreiben

4. Beispiel Programm, um sich Namen von Kunden zu merken: public class CustomerTest... public void testCustomerName() { Customer customer = new Customer("Bent Keck"); assertEquals("Bent Keck", customer.getName()); }

4. Beispiel lassen Klasse erst leer, damit Test fehlschlägt: public class Customer... public Customer(String name) { } public String getName() { return null;

4. Beispiel junit.framework.AssertionFailedError: Fehlermeldung: junit.framework.AssertionFailedError: expected:<Bent Keck> but was:<null> at CustomerTest.testCustomerName(CustomerTest.java:14)

4. Beispiel public class Customer... public String getName() { als nächstes wird Code geschrieben, der Testfall erfüllt  Testfall abgeschlossen public class Customer... public String getName() { return "Bent Keck"; }

4. Beispiel public class Customer... Namen in ein eigenes Feld extrahieren:  wieder grüner Balken public class Customer... private String name = "Bent Keck"; public String getName() { return name; }

5. Warum TDD? ermöglicht es kleine Schritte bei Entwicklung zu machen weniger Bugs, einfachere Behebung für große Projekte geeignet schnelle Entwicklung, jeder Zyklus dauert meist wenige Minuten eigentlich keine Test- sondern Just-in-time-Designstrategie:  gibt frühestmöglich Feedback, ob Design verwendbar sein wird

Vielen Dank!

Quellen http://www.it-agile.de/wissen/praktiken/agiles-testen/testgetriebene- entwicklung-tdd/ http://www.frankwestphal.de/TestgetriebeneEntwicklung.html http://agiledata.org/essays/tdd.html http://www.eecs.yorku.ca/course_archive/2003- 04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf