Testgetriebene Entwicklung mit JUnit

Transkript

1 Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Testgetriebene Entwicklung mit JUnit

2 Testgetriebene Entwicklung Test/Code/Refactor-Zyklus: Motiviere jede Verhaltensänderung am Code durch einen automatisierten Test. Refaktorisierung und einfaches Design: Bringe den Code immer in die Einfache Form. Häufige Integration: Integriere den Code so häufig wie nötig. Paarprogrammierung: Besiege den inneren Schweinehund. 2

3 Zustandsdiagramm der testgetriebenen Entwicklung umstrukturieren Keine Ideen für mehr Testcode Grün (Alle Tests laufen) Zustandsdiagramm idealisiert Testcode vor Anwendungscode Kleine Schritte Inkrementelles Design Testcode schreiben Anwendungscode schreiben Rot (Mindestens ein Test scheitert) 3

4 Test/Code/Refactor-Zyklus grün rot: Schreibe einen Test der fehlschlägt. Schreibe gegebenenfalls gerade soviel Code, dass der Test übersetzt werden kann. rot grün: Schreibe gerade soviel Code, dass alle Tests erfolgreich laufen. grün grün: Eliminiere Duplikationen und andere üble Gerüche im Code. 4

5 Unit Tests werden vom Entwickler selbst geschrieben geben konkretes Feedback und Sicherheit ermöglichen sichere Änderungen sichern Erhalt der vorhandenen Funktionalität müssen bei jeder Code-Integration zu 100 % laufen 5

6 Effizientes Testen möglichst zeitnah zur Programmierung automatisiert und damit wiederholbar muss Spaß machen Testen so oft und so einfach wie Kompilieren Fehler finden, nicht Fehlerfreiheit beweisen 6

7 Testrahmenwerke gibt es für fast jede denkbare Programmiersprache vereinfachen das Schreiben der Testfälle automatische Ausführung der Testfälle und Anzeige der Ergebnisse Zusammenfassen von Testfällen zu Testmengen bekannteste Vertreter für Java: JUnit & TestNG 7

8 JUnit Java-Rahmenwerk zum Schreiben und Ausführen automatischer Unit Tests Ist auch für zahlreiche andere Programmier-sprachen erhältlich Grafische und textuelle Ausgabe In Eclipse integriert 8

9 JUnit 3: Aufbau einer Testfallmethode Signatur: public void test*() throws Exception Testfallmethoden verwenden assert*()und fail() Fehlschlag von assert*() oder Aufruf von fail() beendet Testfall 9

10 Zusicherungen Gekapselt in junit.framework.assert TestCase erbt von Assert Wichtigste Zusicherungen: assertequals(object expected, Object actual) assertequals(double expected, double actual, double delta) assertsame(object expected, Object actual) asserttrue(boolean expression) assertfalse(boolean expression) assertnull(object actual) assertnotnull(object actual) 10

11 JUnit 3: Aufbau einer Testklasse Erbt von junit.framework.testcase Kapseln Testfälle in Testfallmethoden Instanzvariablen für gemeinsame Testobjekte Zum Aufbau von Testressourcen: protected void setup() throws Exception Zur Freigabe: protected void teardown() throws Exception 11

12 Beispiel: Testklasse public class EuroTest extends TestCase { private Euro two; protected void setup() throws Exception { two = new Euro(2.0); public void testadding() throws Exception { Euro sum = two.add(two); assertequals(new Euro(4.0), sum); 12

13 Testmuster für erwartete Ausnahmen public void testnofilehere() throws Exception { try { new File("z:/invalid_name"); fail( FileNotFoundException expected! ); catch (FileNotFoundException ex) { Möglichst robustes Verhalten im Fehlerfall testen. Unerwartete Ausnahmen werden von JUnit als Error registriert. 13

14 Statik von Testfällen junit.framework TestCase # setup() # teardown() Assert + assert*() + fail() EuroTest + testadding() + testamount() + testrounding() Euro + add(euro e) + getamount() + round() 14

15 Dynamik von Testfällen Testfallerzeugung: Pro Testfallmethode wird eine eigene Instanz von TestCase erzeugt. Testlauf: Testfälle laufen ohne Seiteneffekte, ihre Reihenfolge ist prinzipiell undefiniert. :EuroTest :EuroTest setup() setup() testadding() testamount() teardown() teardown() 15

16 Organisation der Testfälle <<interface>> Test * <<implements>> TestCase TestSuite Mehrere Testfälle pro Testklasse (TestCase) Testsuite fasst Testklassen und eventuell weitere Testsuiten zusammen 16

17 Beispiel: Testsuite public class AllTests { [ ] public static Test suite() { TestSuite suite = new TestSuite(); suite.addtestsuite(eurotest.class); suite.addtest(file.alltests.suite()); return suite; 17

18 Testrunner aufrufen public class AllTests { public static void main(string[] args) { TestRunner.run(AllTests.class); [ ] 3 TestRunner: junit.swingui.testrunner junit.awtui.testrunner junit.textui.testrunner Eclipse Plug-in braucht keinen davon. 18

19 Übung 1: Eine Testklasse für die Klasse bank.account public Account(String customer) public String getcustomer() public int getbalance() public void deposit(int amount) public void withdraw(int amount) Für deposit, withdraw sind nur positive Beträge erlaubt, ansonsten wird eine IllegalArgumentException geworfen. 19

20 Wir überlegen uns erste Testfälle Erzeuge neues Konto (Account) für Kunden. Mache eine Einzahlung (deposit). Mache eine Abhebung (withdraw). Überweisung zwischen zwei Konten. Verbiete negative Beträge. 20

21 Wir entwerfen einen Test, der zunächst fehlschlagen sollte public class AccountTest extends TestCase { public void testcreateaccount() { Account a = new Account("Customer"); assertequals("customer", a.getcustomer()); assertequals(0, a.getbalance()); 21

22 Wir schreiben gerade soviel Code, dass sich der Test übersetzen lässt public class Account { public Account(String customer) { public String getcustomer() { return null; public int getbalance() { return 0; 22

23 Wir prüfen, ob der Test fehlschlägt 23

24 Wir schreiben gerade soviel Code, dass der Test erfüllt sein sollte public class Account { public Account(String customer) { public String getcustomer() { return "Customer"; public int getbalance() { return 0; 24

25 Wir prüfen, ob der Test durchläuft 25

26 Wir entfernen Duplikation Aber wo ist sie? public class Account { public Account(String customer) { public String getcustomer() { return "Customer"; public int getbalance() { return 0; public class AccountTest extends TestCase { public void testcreateaccount() { Account a = new Account("Customer"); assertequals("customer", a.getcustomer()); assertequals(0, a.getbalance()); 26

27 Wir entfernen Duplikation public class Account { private String customer; public Account(String customer) { this.customer = customer; public String getcustomer() { return customer; public int getbalance() { return 0; 27

28 Wir prüfen, ob der Test weiterhin läuft 28

29 Tests und Code im Wechselspiel Der fehlschlagende Test entscheidet, welchen Code wir als nächstes schreiben, um die Entwicklung der Programmlogik voranzutreiben. Wir entscheiden anhand des bisher geschriebenen Code, welchen Test wir als nächstes angehen, um die Entwicklung des Designs weiter voranzutreiben. 29

30 Auswahl des nächsten Testfalls Erzeuge neues Konto (Account) für Kunden. Mache eine Einzahlung (deposit). Mache eine Abhebung (withdraw). Überweisung zwischen zwei Konten. Verbiete negative Beträge. 30

31 Nächster Test: Einzahlen public class AccountTest extends TestCase { [ ] public void testdeposit() { Account a = new Account("Customer"); a.deposit(100); assertequals(100, a.getbalance()); account.deposit(50); assertequals(150, a.getbalance()); public class Account { [ ] private int balance = 0; public int getbalance() { return balance; public void deposit(int amount) { balance += amount; 31

32 Rolle der Unit Tests Tests zur Qualitätssicherung: Die Tests sichern die vorhandene Funktionalität Test-First führt zu evolutionärem Design : Das Systemdesign entsteht Stück für Stück. Tests zur Schnittstellendefinition: Test verwendet schon Klassen und Methoden, bevor sie überhaupt definiert sind. Tests zur Modularisierung: Testbarkeit erfordert Entkopplung der Programmteile. Tests als ausführbare Spezifikation und Dokumentation 32

33 Übung 2: Schritt für Schritt Der Quellcode der Euro-Klasse ging verloren, nur die Test wurden gerettet. Zur Erinnerung: Kleine Schritte! Von rot nach grün! Die einfachste Lösung! Mach es lauffähig! Mach es richtig! 33

34 Nachbereitung zu Übung 2 Euro-Klasse ist durch die vorhandenen Tests unterspezifiziert. Viele Tests laufen ohne Codeänderung! Sind diese Tests sinnlos? Welche Tests sollten ergänzt werden? Welche Implementierungsunterschiede sind möglich? 34

35 Testheuristik: Eigenschaften testen, nicht Methoden Testfälle orientieren sich an Anforderungen und Eigenschaften, nicht an den zu testenden Methoden. Es gibt keine 1:1 Entsprechung von Testfallmethode zu getesteter Methode. Testfälle sollen am Beispiel dokumentieren, wie die Klassen korrekt zu verwenden sind. 35

36 Testheuristik: Implementierungsunabhängigkeit Tests sind gegen die öffentliche Klassenschnittstelle gerichtet. Tests, die auf den Innereien einer Klasse basieren, sind äußerst fragil. Sich Zugriff auf Variablen oder private Methoden zu wünschen zeigt, dass dem Code noch eine entscheidende Designidee fehlt. 36

37 Testheuristik: An den Rändern testen Die meisten algorithmischen Fehler treten an den Rändern der erlaubten Wertebereiche auf: Auswahl der Testexemplare dort, anstatt irgendwo! Lässt sich der Wertebereich in mehrere für den Test äquivalente Proben unterteilen? Pro Äquivalenzklasse mindestens eine Probe! 37

38 Testheuristik: Ergebnisse im Test festschreiben Erwartete Werte werden als Konstanten kodiert, nicht noch mal im Test berechnet. Reproduzieren wir Anwendungslogik im Test, reproduzieren wir auch ihre Fehler. 38

39 Testheuristik: Orthogonale Testfälle Unabhängig voneinander sind Testfälle dann, wenn sie sich auf orthogonale Aspekte beziehen. Häufig lässt sich ein Test extrem vereinfachen, indem er Annahmen macht, die ein anderer Test bereits verifiziert hat. Kommt man in die Not, zu viele Tests anpassen zu müssen, nur um eine Codeänderung machen zu können, sind die Tests nicht orthogonal. 39

40 Testheuristik: Testklassen 1:1 Entsprechung zwischen Testklasse und Anwendungsklasse ist nicht zwingend. Testklassen sind ein Mechanismus für die Wiederverwendung von Testcode. Testklassen, die einen ähnlichen Testrahmen benötigen, sind in einem Paket. 40

41 Weitere Testheuristiken Vergiss Ausnahmen und Fehlerfälle nicht! Wähle aussagekräftige Testklassen- und Testmehtodennamen! Entferne Redundanz im Testcode! Halte Testfälle kurz und verständlich! 41

42 Testtechnik: Mock-Objekte Testen von innen zahlreiche Bibliotheken: EasyMock, jmock ersetzen eine echte Implementierung und verifizieren korrektes Verhalten des Klienten Unterscheide Mock-Objekte von Stummel- Objekten und Attrappen Stummel-Objekte und Attrappen ersetzen auch echte Implementierung für Testzwecke Stummel-Objekte und Attrappen verifizieren selbst nichts 42

43 Testmuster für Mock-Objekte Instanzen der Mock-Objekte erstellen initiale Zustände der Mock-Objekte setzen erwartete Werte der Mock-Objekte setzen Anwendungscode mit Mock-Objekten als Parameter aufrufen Verifizieren der erwarteten Werte in den Mock- Objekten 43

44 Typischer Ablauf eines Tests mit Mock-Objekt :Test setup() testx() create create m:mock :CUT weitere Initialisierung des Mock-Objekts init() x(m) verify() y() weitere Verwendung des Mock-Objekts 44

45 Vorteile von Mock-Objekten gut zum Testen von Protokollen, der richtigen Reihenfolge von Methodenaufrufen und den dabei übergebenen Parametern reduzieren Abhängigkeiten reduzieren Wartezeiten kapseln/beschreiben erwartetes Verhalten können Verhalten zeigen, dass ansonten schwer zu reproduzieren ist fördern Programmierung gegen Schnittstellen 45

46 Indikatoren gegen das Testen mit Mock-Objekten Mock-Objekt enthält viel Logik statt fest verdrahteter Werte Mock-Objekt dupliziert Anwendungslogik echte Objekte leicht(er) verwendbar Mock-Objekt ruft andere Mock-Objekte auf 46

47 Referenzen Kent Beck: Extreme Programming Explained - Embrace Change. Addison-Wesley, Kent Beck: Test-Driven Development: By Example. Addison-Wesley, Martin Lippert et al.: Software entwickeln mit extreme Programming. Erfahrungen aus der Praxis. dpunkt.verlag, Johannes Link: Softwaretests mit JUnit, 2. Auflage. dpunkt.verlag, Frank Westphal. Testgetreibene Entwicklung mit JUnit & FIT. dpunkt.verlag,