AdvancedTdd

Fortgeschrittene Techniken der Testgetriebenen Entwicklung JAX Powerworkshop, 23.04.2007 Tammo Freese, Johannes Link

Agenda • Testgetriebene Entwicklung im Überblick • Akzeptanztests mit FIT • Unit Tests mit JUnit/Mockobjekte mit EasyMock • Legacy Code und Code Coverage • Testen von GUIs und Web-Applikationen • Testen mit Skriptsprachen • Diskussion

Motivation • Software hat Geschäftswert durch zwei Qualitäten • Funktionale Qualität (Funktionalität, Fehlerfreiheit) • Strukturelle Qualität (Design/Codestruktur für Weiterentwicklung) • Hinzufügen neuer Funktionalität gefährdet funktionale und strukturelle Qualität • Verbesserung der strukturellen Qualität gefährdet die funktionale Qualität

Testgetriebene Entwicklung • Testgetriebene Programmierung: Motiviere jede Verhaltensänderung am Code durch einen automatisierten Test (ständige Absicherung der funktionalen Qualität) • Refactoring: Vereinfache das Code-Design soweit wie möglich (funktionale Qualität ist durch Tests abgesichert) • (Häuﬁge Integration: Integriere den Code so häuﬁg wie nötig)

Entwickler schreiben Unit Tests • testen Komponenten des Systems in Isolation • geben uns konkretes Feedback • ermöglichen sichere Änderungen • sichern Erhalt der vorhandenen Funktionalität • müssen bei jeder Integration zu 100% laufen • können funktionale Tests auf Systemebene nicht ersetzen!

Kunden speziﬁzieren Akzeptanztests • testen das System überwiegend als Ganzes • geben unseren Kunden Vertrauen in die gelieferte Software • klären die Anforderungen frühzeitig an konkreten Beispielen • machen den Projektfortschritt sichtbar • müssen vom Kunden erstellt und gepﬂegt werden können • Unsere Aufgabe ist es, den entsprechenden Rahmen für ihre Automatisierung zu schaen!

Akzeptanztests mit FIT • FIT: Framework for Integrated Test • Zum Schreiben und Ausführen automatischer Akzeptanztests • Testdaten werden tabellarisch erstellt (in HTML, mit Excel oder im Wiki) • Anbindung ans System in Java • Portierung für aktuelle Sprachen verfügbar • http://ﬁt.c2.com

Drei Fixture-Klassen • ColumnFixture testet Ein-/Ausgabewertemengen. • ActionFixture spielt ein Benutzerszenario durch und ist deshalb gut für GUI-orientierte Tests geeignet. • RowFixture prüft eine Ergebnismenge von Objekten mit ihren Attributen.

Column Fixture (1)

Column Fixture (2) import fit.ColumnFixture; public class AccountTransferFixture extends ColumnFixture { public String sourceAccount; public String targetAccount; public double amountTransferred; public boolean wasTransactionSuccessful() throws AccountException { return false; } }

Action Fixture (1)

Action Fixture (2) import fit.ActionFixture; public class AccountAdministrationFixture extends ActionFixture { public void newAccount() {} public void customerName(String name) {} public String accountNumber() { return "0"; } public void deposit(double money) throws AccountException { } public double balance() { return 0; } }

Row Fixture (1) public class AccountListingItem { public String accountNumber; public double balance() { return 0; } public String customerName() { return "dummy"; } }

Row Fixture (2) import fit.RowFixture; public class AccountListingFixture extends RowFixture { public Object[] query() throws Exception { List result = new ArrayList(); return result.toArray(); } public Class getTargetClass() { return AccountListingItem.class; } }

Domänenspeziﬁsche Fixtures • wenn keine Fixture-Grundart so richtig passt • Erweiterungen von fit.Fixture über Hook- Methoden: • doTables(Parse tables) • doTable(Parse table) • doRows(Parse rows) • doRow(Parse row) • doCells(Parse cells) • doCell(Parse cell, int index)

Übung 1: Akzeptanztestgetriebene Entwicklung • Bringen Sie die Testfälle in acceptance-tests/RichCalc.html schrittweise zum laufen! • (TaschenrechnerFixture.java ist eine ColumnFixture)

Nachlese Übung 1 • Probleme bei akzeptanztestgetriebener Entwicklung • (Zu) große Schritte: Es dauert oft zu lange, einen Test auf grün zu bringen • Keine Möglichkeit, Design zu erzwingen • Keine Möglichkeit, Module isoliert ins Leben zu testen • Kombinatorische Explosion • Lösung: Unit Tests • Viele kleine Unit Tests schreiben • Jeden Akzeptanztest schrittweise erfüllen

JUnit - Testframework für Java • Java-Framework zum Schreiben und Ausführen automatischer Unit Tests • Tests werden in Java codiert • Ist auch für zahlreiche andere Programmiersprachen erhältlich • http://junit.org

Beispiel: Test import org.junit.Test; import static org.junit.Assert.*; public class EuroTest { @Test public void cents() { Euro two = new Euro(2.00); assertEquals(200, two.getCents()); } }

Anatomie eines Testfallklasse • Testfallmethoden @Test public void ...() • Verwendung der statisch importierten Methoden assert...() und fail() • Fehlschlag von assert...() beendet den Testfall • Instanzvariablen für Testobjekte • @Before public void ...() zum Aufbau von Testobjekten und Testressourcen • @After public void ...() zur Ressourcenfreigabe

Beispiel: Test Suite import org.junit.runner.RunWith; import org.junit.runners.Suite; import org.junit.runners.Suite.SuiteClasses; @RunWith(value = Suite.class) @SuiteClasses( { CalculatorTest.class }) public class AllTests { }

Eclipse: JUnit Testrunner

Test/Code/Refactor – Zyklus JUnit: Failure JUnit: OK

Test/Code/Refactor – Schritte • grün-rot: Schreibe einen Test, der zunächst fehlschlagen sollte. Schreibe gerade soviel Code, dass der Test fehlschlägt. • rot-grün: Schreibe gerade soviel Code, dass alle Tests laufen. • grün-grün: Eliminiere Duplikation und andere üble Codegerüche.

Programmierzug grün - rot • Programming by Intention: Der Test verwendet die zu testende Funktion, als wäre sie schon realisiert. • Die Klassenschnittstelle wird im Test aus der Perspektive eines Verwenders entworfen. • Jeder Test geht einen kleinen Schritt. • Den Test zunächst fehlschlagen zu sehen, testet den Test selbst.

Programmierzug rot - grün • Nur soviel Code schreiben, wie die Tests erfordern. • Mehr wäre weder durch die Tests speziﬁziert, noch abgesichert. • Erst weitere Tests beweisen, dass die Lösung eventuell noch zu einfach ist.

Refactoringzug grün - grün • Eliminierung von Duplikation! • Verbesserungen am Design des Programms, ohne sein beobachtbares Verhalten zu ändern, • um die Verständlichkeit zu erhöhen • um Designschwächen zu beheben • um die Änderbarkeit zu erhalten.

Strikte Unit Tests • Ein Unit Test soll eine Klasse oder ein Klassenteam in Isolation testen. • Probleme: • Programmeinheiten arbeiten nicht isoliert. • Aufbau der Testumgebung ist oft aufwändig. • Testen von Ausnahmesituationen • langsame Tests bei Überschreiten der Systemgrenzen

Isoliertes Testen • Für die Dauer der Tests ersetzen wir Abhängigkeiten zu mitwirkenden Programmeinheiten durch die Einführung einfacher Attrappen. • Vorteile: • Tests laufen schnell. • Auftretende Fehler sind leicht zu lokalisieren. • Notwendige Testkombinatorik ist kleiner als beim Testen mehrerer Objekte.

Isoliertes Testen

Mock-Objekte • Ersetzen von der zu testenden Unit verwendeten Klassen oder Schnittstellen während des Tests • Vorgehen: • Verhalten und Erwartungen speziﬁzieren • Unit unter Verwendung des Mockobjekts testen • korrekte Verwendung veriﬁzieren

EasyMock – Dynamische Mock-Objekte • Erzeugung eines Mock-Objekts „on the ﬂy“: • MyInterface mock = createMock(MyInterface.class); • Aufzeichnen des erwarteten Verhaltens: • expect(mock.myMethod(42))andReturn("Y"); replay(mock); • Veriﬁkation der Verwendung des Verhaltens: • verify(mock); • http://easymock.org/

Systemgrenzen im Test • Dummies und Mocks: • Was wir zur Isolation innerhalb des Systems verwenden, funktioniert auch an Systemgrenzen. • Bei komplexen Systemgrenzen: • Fassade/Adapter zur zusätzlichen Indirektion einführen • Testen vom System zu Fassade/Adapter • Testen von Fassade/Adapter zur Systemgrenze • funktionale Tests testen das Zusammenspiel

Übung 2: Isolierte Unit Tests • Bringen Sie die Testfälle in acceptance-tests/RichCalc.html schrittweise zum laufen! • Diesmal aber: • Schreiben Sie Unit Tests für die Akzeptanztests • Setzen Sie Mockobjekte ein, falls nötig • Startlinie: calculator.unittests.CalculatorTest

Code Coverage • Wie gut sind unsere Tests? • Wie groß ist die Abdeckung des Codes durch unsere Tests? • http://www.cenqua.com/clover/ • http://works.dgic.co.jp/djunit/ • http://www.eclemma.org/ • Welche Code-Änderungen werden durch unsere Tests entdeckt? • http://jester.sourceforge.net/ • Metriken als Spiegel der Gewohnheit

Testen von Legacy Code • Legacy Code ist Code ohne automatisierte Tests! • Michael Feathers: „Code without tests is bad code. It doesn't matter how well written it is [...] With tests, we can change the behavior of our code quickly and veriﬁably. Without them, we really don't know if our code is getting better or worse.“

Legacy Code Dilemma • Um Software sicher zu ändern, benötigen wir automatisierte Tests. • Um automatisierte Tests zu schreiben, müssen wir die Software ändern. • Refactoring ohne Tests unumgänglich

Testen von bestehendem Code • Änderung des bestehenden Systems • neue Features • Entfernen von Bugs • Designverbesserungen • Optimierungen • Vergrößerung der Testabdeckung • Testgetriebene Entwicklung • Charakterisierende Tests • Integrationstests

Störende Abhängigkeiten • Eine Klasse lässt sich nicht instanzieren • Eine Methode lässt sich nicht ausführen • Das Testergebnis lässt sich nicht ermitteln

Vorgehen 1. Identiﬁziere Änderungspunkte 2. Finde Testpunkte 3. Brich Abhängigkeiten 4. Schreibe automatisierte Tests 5. Mache Änderung 6. Räume auf (Refactoring)

Werkzeugkasten • Automatisierte Refactorings • JUnit Test-Framework • Mock-Objekte als Attrappen • Framework for Integrated Test (FIT) • Aspektorientierte Programmierung

Einschleusen von Mocks • als Parameter • über testbare Unterklasse • mittels Überlagerung im Klassenpfad • mit aspektorientierter Programmierung • in C/C++ auch über Linker und Präprozessor • Jedes Testproblem lässt sich über eine weitere Indirektion lösen

Meine Klasse lehnt sich gegen den Test auf • Ursachen: • Klasse kann nicht instanziert werden • Hinderliche Konstruktor-Parameter • Konstruktor hat Seiteneekte • Techniken: • Extrahiere und überschreibe Methode • Extrahiere Interface • Parametrisiere Konstruktor

Extrahiere und Überschreibe (1) public class A { public class A { public A() { public A() { B b = makeB(); B b = new B(); b.doStuff(); b.doStuff(); ... ... } } protected B makeB() { } return new B(); } }

Extrahiere und Überschreibe (2) public class TestableA extends A { protected B makeB() { return new DummyB(); } } public class DummyB extends B { public void doStuff() { } }

Extrahiere Interface public class A { public class A { public A() { public A() { IB b = makeB(); B b = makeB(); b.doStuff(); b.doStuff(); ... ... } } protected IB makeB() { protected B makeB() { return new B(); return new B(); } } } }

Parametrisiere Konstruktor public class A { public class A { private IB b; public A() { public A(IB b) { IB b = makeB(); this.b = b; b.doStuff(); b.doStuff(); ... ... } } } public A() { this(new B()); } }

Weitere Techniken • Abzweigende Methode • Abzweigende Klasse • Statisch gemachte Methoden • Primitivere Parametertypen • Führe statischen Setter ein • Führe delegierende Instanz ein • Ersetze Singleton durch direkte Abhängigkeit • Extrahiere Methoden • Extrahiere Methodenobjekt

Verbesserungen über die Zeit • Viele der Techniken machen das Design zunächst einmal hässlicher • Durch die ersten installierten Tests sind kleine Verbesserungen möglich • Kleine Verbesserungen lassen weitere Refactoringkandidaten erkennen • Schrittweise zu evolutionärem Design

Testen von GUIs und Web-Applikationen • Wichtigster Grundsatz: Keine Logik im View • Entwurfsmuster zur Trennung von Präsentation und Geschäftslogik: • Application Facade • Model View Presenter

Application Facade <<interface>> BookSearchFacade BookSearchDialog searchTitles(searchExpression:String) : List Book Title Author

Application Facade mit Observer <<interface>> Observer changeOccurred() <<implements>> <<interface>> BookSearchFacade BookSearchDialog searchTitles(searchExpression:String) : List registerObserver(observer: Observer) changeOccurred() Book Title Author

Model View Presenter <<interface>> <<interface>> BookSearchView BookSearchPresenter displayList(books:List) search (searchExpression:String) <<implements>> <<implements>> BookSearchDialog BookSearcher displayList(books:List) search (searchExpression:String)

Testen mit Skriptsprachen • Dynamisch typisierte Skriptsprachen können das Testen vereinfachen • Beispiel Groovy: • Alle Java-Features und Bibliotheken verfügbar • Typisierung ist optional • „Duck-Typing“ ist möglich • Einfache Syntax für Blocks und Iteratoren

Groovy: Vereinfachte Syntax • Viele Elemente optional: • public, Typisierung, Parameterklammern, Semikolon class CalculatorTest extends GroovyTestCase { private calculator void setUp() { calculator = new Calculator() ... } void testDisplayThreeDigits() { checkDisplay '1', '5', '9' } def checkDisplay(String[] buttons) { ... }

Groovy: Closures und Collections • Einfache Blocksyntax • Mächtige Collections • Iteratoren mittels Blöcken def printer = { line -> println line } printer('Test') def buttons = ["1", "2", "3", "4"].reverse() def displayText = "" buttons.each { displayText += it } assert displayText == "4321"

Groovy: Dynamisch typisierte Objekte • „Anonyme“ Objekte on the ﬂy def display = {assert it == displayText} as IDisplay def display = [display: {println it}, enableDecimalSeparatorKey: { ... }, disableDecimalSeparatorKey: { ... } ] as IDisplay

Übung 3: Wie es euch gefällt • Variante 1: Schreiben Sie mit Hilfe von Jemmy eine Taschenrechner-Fixture, die direkt die Swing-GUI bedient • Variante 2: Erweitern Sie die Groovy-Testsuite im Package groovy.calculator.unittests • Variante 3: Erweitern Sie GUI und GUI-Tests: public interface IDisplay { void display(String toDisplay); void disableDecimalSeparatorKey(); void enableDecimalSeparatorKey(); }

Fragen & Diskussion

Referenzen • Michael Feathers: Working Eectively with Legacy Code. Prentice Hall, 2004. • Johannes Link: Softwaretests mit JUnit - Techniken der testgetriebenen Entwicklung. Dpunkt-Verlag, 2005. • Rick Mugridge, Ward Cunningham: Fit for Developing Software. Prentice Hall, 2005. • Frank Westphal: Testgetriebene Entwicklung mit JUnit & FIT. Dpunkt-Verlag, 2005.

AdvancedTdd

by jlink on Apr 26, 2007

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 3

Statistics

AdvancedTdd — Presentation Transcript