Gestatten: Hudson. Augmented Development. Thomas Kruse. Sun Campus Ambassador

Transkript

1 Gestatten: Hudson Augmented Development Thomas Kruse Sun Campus Ambassador 1

2 Zum Referenten Thomas Kruse Java Entwickler seit 1998 Mitgründer der Java Usergroup Münsterland: jug-muenster.de Sun Campus Ambassador an der WWU Münster 2

3 Agenda Testen kostet nur Zeit Junit Mock Hudson Netbeans Integration Live Demo Ausblick Q&A 3

4 Testen kostet nur Zeit 4

5 Beispiel: Fibonacci Zahlen //returns the n-th fibonacci //number. public class FibonacciExample { public static int calc (Integer n) { if (n == 1) return 1; if (n == 2) return 1; return calc(n-1)+calc(n-2); } } 5

6 Manuelles Testen Manuelles Testen > Annahme: Es geht eh nichts schief > (d.h. keine Wiederholungen des Testens) Und? FibonacciExample.calc(1) 1 > geht doch! FibonacciExample.calc(0) > hoppla (potentiell vom Kunden gemeldet) 6

7 Fibonacci Zahlen - verbessert //returns the n-th fibonacci //number. public class FibonacciExample { public static int calc (Integer n) { if (n==0) return 0; if (n == 1) return 1; if (n == 2) return 1; return calc(n-1)+calc(n-2); } } 7

8 Manuelles Testen (2) Und? FibonacciExample.calc(0) 0 > geht doch! FibonacciExample.calc(-1) > hmpf Rechtzeitig entdeckt kein Problem > Aber wann ist rechtzeitig? 8

9 Fibonacci Zahlen jetzt noch besser //returns the n-th fibonacci //number. public class FibonacciExample { public static int calc (Integer n) { if (n < 0) return 0; if (n == 1) return 1; if (n == 2) return 1; return calc(n-1)+calc(n-2); } } 9

10 Manuelles Testen (3) Und? FibonacciExample.calc(-1) 0 > geht doch! Fertig! > alle relevanten Bedingungen getestet > wirklich? FibonacciExample.calc(null) NPE > Alle Randbedingungen bedenken Bugfixing > Keine Garantie dass nicht alte Fehler wiederkehren 10

11 Testen spart Zeit und Geld! Testen ist nicht vermeidbar, aber: Testen einplanen > Wie würde ich das testen - führt zu Einfachheit > erhöht den Grad der Wiederverwendbarkeit und auch durchführen > Erhöht die Sicherheit bei Änderungen > Dokumentation der Software über Beispiele > einfachere Kooperation im Team > Bugfix Kosten steigen immens mit jeder Projektphase! 11

12 Testen, aber richtig! Kerngedanken > Kooperation testbarer Komponenten > Jede Methode erfüllt abgegrenzte Aufgabe > Abhängigkeiten (DB, externe Systeme) isolieren > Implementierung gegen Interfaces > Randbedingungen checken Am besten mit Tool Unterstützung > Automatische Testausführung Übung macht den Meister 12

13 Was muss getestet werden? Nicht: Externe Bibliotheken, JVM, Classlibrary > z.b. HashMap Bei unit Tests: Nicht externe Systeme > z.b. arbeitet DB korrekt? Speichert Filesystem? Erwartetes und Unerwartetes > Erwartete Fehler (DB Exception, DB futsch) > null statt Objekt > Negative Werte, 0, leere Strings > falsche Verwendung 13

14 Testen mit JUnit 14

15 Motivation automatische Softwaretests Manuelle Tests > Fehleranfällig, hoher Aufwand bei wiederholter Ausführung Lösung: Tests Teil der Software! > Tests gehören zu guter Software dazu > Dokumentieren Verwendung und Randbedingungen > Wartung ist integraler Bestandteil vergleichbar der Wartung beim PKW Vorhandene Tests vermeiden Regressions > Mehr Sicherheit bei Refactoring, Bugfixing, Changes 15

16 JUnit Überblick Framework um Testen zu vereinfachen Ermöglicht Automatisierung > Programmatischer Aufruf Standard einmal lernen, überall zurecht finden Integration in Entwicklungsumgebungen > Schnelle und häufige Durchführung bei der Entwicklung Sprachübergreifende Verbreitung > unit.net, phpunit,... 16

17 JUnit am Beispiel Fibonacci Erwartetes Ergebnis bestimmen > von Hand oder bereits bekannte Werte > Test mit Eingabe und jeweils erwarteter Ausgabe Beispiel für Test auf -1 und 0 > Test verwendet JUnit und Java 5 Annotations Tests sind genauso zu pflegen wie die eigentliche Software! 17

18 Fibonacci Test Code import org.junit.test; import static org.junit.assert.*; public class FibonacciExampleTest public void testfornegativeinput() { Integer n = -1; int expected = 0; int result = FibonacciExample.calc(n); assertequals(expected, result); } } 18

19 Testausführung IDE > Netbeans, Eclipse,... > Ein Klick Kommandozeile > Textinterface > Swing Interface Andere Programme > Continuous Integration 19

20 Unit Tests vs. Integrationstest Unit Tests sollen einzelne Software Komponenten testen Ein Integrationstest dient dazu Softwarekomponenten im Zusammenspiel mit abhängigen Komponenten zu testen Systemtest beinhaltet vollständigen Test der Software, meist mit Testdaten auf Testsystem Akzeptanztest dient schließlich der Abnahme 20

21 Isolation bringt Probleme Viele Klassen benötigen Zuarbeit Abhilfe: Kollaborateure ebenfalls im Test simulieren > Nachteil: Viel Boilerplate Code wenn z.b. Datenbankinterfaces implementiert werden Wird Testen eingeplant, bleiben die Abhängigkeiten meist überschaubar Gerade bei Bestandssystemen wird Unit Testen jedoch schwer 21

22 Mock: So tun als ob 22

23 Beispiel: Registrierung bei Onlineshop Bereits existierender Kunde soll sich nicht doppelt registrieren > Unit Test der für die Validierung zuständige Teil soll getestet werden > Ohne Datenbank, Testsystem, Testdaten oder gar noch der verwendeten Datenbank oder des Webservers Der Validator nutzt jedoch gerade die Datenbank: Es geht um Doppelregistrierungen! 23

24 Lösung: Mock Objekte Datenbank(inhalt) wird für den Test simuliert > Mock Objekte sind Attrappen und helfen Abhängigkeiten von zu testenden Units aufzulösen > Sehr schnell: Keine externen Systeme > Überall durchführbar, auch auf Entwickler Laptop im Flugzeug > Auch schwer zu erzeugendes Verhalten (Netzwerkfehler, Temperatur) kann simuliert werden 24

25 Ablauf bei Mock-Objekten Mock Objekt eines Interfaces bzw. einer zu simulierenden Klasse erzeugen Erwartetes Verhalten aufzeichnen Auf Wiedergabe umstellen (replay) Ablauf Verifizieren (verify) > Optional, aber oft hilfreich > Strict: Reihenfolge der Methodenaufrufe wird ebenfalls kontrolliert (EasyMock.createStrictMock() ) > Nice: Keine Exception bei unerwarteten Calls 25

26 Benutzerregistrierung mit Mocking Das Beispiel der Benutzerregistrierung hat im wesentlichen zwei zu testende Ausprägungen: > Benutzer existiert bereits in der Datenbank > Benutzer existiert noch nicht > Zwei Unit Tests mit entsprechenden Mock Objekten Beispielcode in Java und EasyMock > Andere Mockframeworks verfügbar, auch für andere Plattformen 26

27 EasyMock Beispiel public class CustomerManagerTest { private CustomerDao customerdao; private CustomerManager protected void setup() throws Exception { super.setup(); customerdao = EasyMock.createMock(CustomerDao.class); customermanager = new CustomerManager(); customermanager.setcustomerdao(customerdao); public void testexistinguser() { Customer existing = new Customer(); EasyMock.expect(customerDao.find( Thomas, Kruse )).andreturn(existing); EasyMock.replay(customerDao); try { customermanager.createnew( Thomas, Kruse ); //just an example fail( Creating an existing customer should result in Exception ); } catch (CustomerExistsException expected){} EasyMock.verify(customerDao); } } 27

28 EasyMock Beispiel public void testnotexistinguser() { Customer created; EasyMock.expect(customerDao.find( Thomas, Kruse )).andreturn(null); EasyMock.replay(customerDao); created = customermanager.createnew( Thomas, Kruse ); //just an example EasyMock.verify(customerDao); //possible validation of created customer object //for example creation date not null,... } } 28

29 Dependency Injection Idee: Abhängigkeiten nicht selber auflösen, sondern sich konfigurieren lassen > Vermeidet Abhängigkeit von JNDI bzw. Registry > Erhöht Wiederverwendbarkeit des Codes Kann mit oder ohne Frameworkunterstützung realisiert werden Viele prominente DI Frameworks: > Google Guice > Spring Framework > EJB 3 29

30 Best practices Immer gegen Interfaces entwickeln > Erlaubt einfaches mocken > Bei guten Interfaces auch den Austausch von Implementierungen Dependency Injection > Erleichtert Testen und einfachere Wartung Tests sagen mehr als 1000 Zeilen JavaDoc > Aber auch JavaDoc nicht vergessen Bestandssoftware warten? > Statt Komplett neu ist Refactoring denkbar 30

31 Esoterische Bugs Kollege schwört: Bei mir tat es aber > Besonderheiten der Entwicklungsumgebung > z.b. Betriebssystem, Java Version, Zustand > Häufig: Nicht alle Änderungen im VCS Da nützen auch keine Tests oder doch? Lösung: Continuous Integration > In klar definierter Umgebung > Klar definierten Stand nutzen > Und testen (lassen) 31

32 Hudson 32

33 Continuous Integration: Hudson Continuous Integration > Automatisch > Reproduzierbar > Permanent Hudson > Kostenlos > Sehr flexibel und stabil > Auch für nicht-java Projekte (z.b..net) > Gute Community 33

34 Hudson Einrichtung: Download Download > 34

35 Hudson Einrichtung: Starten Starten > java -jar hudson.war > Oder in Servlet Container deployen 35

36 Hudson Verwenden: Browser Verwendung per Webbrowser > 36

37 Hudson Verwenden: Plugins Zusätzliche Funktionen > z.b. Maven 37

38 Netbeans Integration 38

39 Mehr Komfort... Alles was schwierig ist, wird selten gemacht Übersicht über alle Projekte Testfehler in der IDE direkt im Code aufrufen Changelogs, diffs in der IDE analysieren Generierte Artefakte direkt in IDE verfügbar Bei Maven Projekten erkennt Netbeans im pom.xml eingetragene CI Server > Sonst manuell anlegen 39

40 und Einschränkungen Projekt muss alle nötigen Abhängigkeiten mitbringen > auch JUnit! (junit.jar) oder aber auflösen können > Maven, Ivy > Andere Hudson Projekte ( promotion plugin ) Projekt muss in Version Control System vorliegen > z.b. Mercurial: hg serve Kann bei etablierten Projekten schwierig sein 40

41 Vorbereitung: Versionskontrolle Hudson-Mercurial Plugin installieren Projekt via Mercurial zur Verfügung stellen > z.b. hgserve (simpler HTTP Server) > Push ohne SSL und Authentifizierung erlauben:.hg/hgrc [web] push_ssl = false allow_push = * 41

42 Vorbereitung: Netbeans Netbeans muss das Projekt mit VCS kennen > am besten auschecken 42

43 Netbeans trifft Hudson Grafische Einrichtung 43

44 Netbeans build job 44

45 Fertiger build job Zugriff auf Jobs, Artefakte Build Ergebnisse 45

46 Ausblick Zusätzliche Tools zur Code Analyse > Findbugs > CPD > Code-Coverage Version Control System (VCS) > z.b. Subversion, git, Mercurial > Automatisches tagging: Stabiler Stand für alle. Jederzeit. Integration von Issue Trackern (Jira, Trac, ) Build Slaves/Matrix 46

47 Q&A 47

48 Nächste Schritte... JUnit verwenden Hudson Download > Bessere Software mehr Spaß! > und es spart Zeit Java Usergroup Münster > Tipps und Austausch > Konkrete Hilfe bei Fragen! 48

49 Links und Resourcen Junit: EasyMock: Hudson: Netbeans: Mercurial: Findbugs: PMD: (CPD) Slides: 49

50 Danke für Ihre Zeit! Fragen? Hudson + Netbeans Augmented Development Thomas Kruse Sun Campus Ambassador thomas.kruse@sun.com ICQ: