Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

JUnit für Fortgeschrittene

Ähnliche Präsentationen


Präsentation zum Thema: "JUnit für Fortgeschrittene"—  Präsentation transkript:

1 JUnit für Fortgeschrittene

2 2 Übersicht Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB static und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB static und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion

3 3 Ziele des Vortrags Separates Testen von Klassen Abhängigkeiten auflösen Testen bis in die Nähe der Systemgrenzen Reines JUnit, nicht darauf aufsetzende Tools (HttpUnit, Cactus,...) Separates Testen von Klassen Abhängigkeiten auflösen Testen bis in die Nähe der Systemgrenzen Reines JUnit, nicht darauf aufsetzende Tools (HttpUnit, Cactus,...)

4 4 Kurze Wiederholung JUnit macht Spaß aber in der Praxis gibt es manche Hindernisse Funktionalität ist testbar Normalfälle, Fehlerfälle, Integration Methoden-, Klassen-, Systemebene Grenzen Performance-Tests Multithreading GUI JUnit macht Spaß aber in der Praxis gibt es manche Hindernisse Funktionalität ist testbar Normalfälle, Fehlerfälle, Integration Methoden-, Klassen-, Systemebene Grenzen Performance-Tests Multithreading GUI

5 5 Gute JUnit-Tests Kriterien für eine gute Test-Suite: Schnelles Durchlaufen Gute Abdeckung Vertrauen vollständig ist aber schlechtes Ziel Automatische Ausführbarkeit automatisierter Build-Prozess Einfach zu erstellen / pflegen Kriterien für eine gute Test-Suite: Schnelles Durchlaufen Gute Abdeckung Vertrauen vollständig ist aber schlechtes Ziel Automatische Ausführbarkeit automatisierter Build-Prozess Einfach zu erstellen / pflegen

6 6 Übersicht Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB static und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB static und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion

7 7 Problem Eine einzelne Klasse ist leicht zu testen. Im echten Projekt ist es oft anders. Wenn Klassen von einander abhängen, kann man sie nur noch zusammen testen. Abhängigkeiten sind oft nur implizit. Eine einzelne Klasse ist leicht zu testen. Im echten Projekt ist es oft anders. Wenn Klassen von einander abhängen, kann man sie nur noch zusammen testen. Abhängigkeiten sind oft nur implizit. Statistik Kundenverwaltung Kundenpersistenz Schufaanfrage Netzwerk

8 8 Problem (2) sogenannter Pragmatismus: Dann testet man eben nicht so gründlich... Sonderfälle bei der Datenbelieferung Fehlerfälle und Exceptions seltene Testausführung wegen Aufwand für Deployment und Infrastruktur sogenannter Pragmatismus: Dann testet man eben nicht so gründlich... Sonderfälle bei der Datenbelieferung Fehlerfälle und Exceptions seltene Testausführung wegen Aufwand für Deployment und Infrastruktur

9 9 Mock Objects Code über Interface ansprechen Test-Implementierung für JUnit-Test Initialisierung: Konstruktor oder per Parameter Code über Interface ansprechen Test-Implementierung für JUnit-Test Initialisierung: Konstruktor oder per Parameter Statistik Kundenverwaltung StatistikDatenquelleKundenStatistikDatenquelle StatistikTestMockDatenquelle

10 10 Praktisches Beispiel Ein Quelltext sagt mehr als tausend Folien...

11 11 Konkretes Vorgehen Mock Object initialisieren Zustand setzen Verhalten parametrisieren Mock Object an getesteten Code übergeben Zustand des Mock Objects verifizieren Mock Object initialisieren Zustand setzen Verhalten parametrisieren Mock Object an getesteten Code übergeben Zustand des Mock Objects verifizieren

12 12 Größere Perspektive Testbarkeit prägt das Design! explizite Abhängigkeiten Refactoring Verschiedene Anwendungsgebiete Geschäftslogik Systemschnittstellen Logger etc. Testbarkeit prägt das Design! explizite Abhängigkeiten Refactoring Verschiedene Anwendungsgebiete Geschäftslogik Systemschnittstellen Logger etc.

13 13 Übersicht Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB static und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB static und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion

14 14 Grenzen sind komplex Probleme mit Tests: schnell laufen: Interaktion kann Zeit kosten Abdeckung: Verhalten externer Teile schlechter zu kontrollieren Automatisch: Synchronisierung von Tests und externen Systemen Einfach zu erstellen: Externer Aufwand Auch bei externen Bibliotheken Probleme mit Tests: schnell laufen: Interaktion kann Zeit kosten Abdeckung: Verhalten externer Teile schlechter zu kontrollieren Automatisch: Synchronisierung von Tests und externen Systemen Einfach zu erstellen: Externer Aufwand Auch bei externen Bibliotheken

15 15 Zugriff durch Wrapper Die eigentliche System-Schnittstelle hinter Interface kapseln z.B. HttpSender, FilePersister,... fertige Mock Objects Test-Implementierungen können Sonderfälle / Exceptions simulieren Design-Option: Decorator, Caching, Filter etc. Refactoring Die eigentliche System-Schnittstelle hinter Interface kapseln z.B. HttpSender, FilePersister,... fertige Mock Objects Test-Implementierungen können Sonderfälle / Exceptions simulieren Design-Option: Decorator, Caching, Filter etc. Refactoring

16 16 z.B. Netzwerkkommunikation Client versendet Strings per HTTP Netzwerkkommunikation über Schnittstelle Mock-Implementierung für Tests weitere nützliche Implementierungen Client versendet Strings per HTTP Netzwerkkommunikation über Schnittstelle Mock-Implementierung für Tests weitere nützliche Implementierungen ClientServerCommunicator HttpServComm NullServCommTimeoutServComm ClientTestMockServComm Netzwerk

17 17 Praktisches Beispiel Ein Quelltext sagt mehr als tausend Folien...

18 18 Datenbanken Alternative: Durchgriff auf die Datenbank Testet Spezialitäten des DB-Systems Testet die eigentliche Persistenzschicht Macht Abhängigkeiten im Datenmodell deutlich Jeder Entwickler braucht eine Datenbank Alternative: Durchgriff auf die Datenbank Testet Spezialitäten des DB-Systems Testet die eigentliche Persistenzschicht Macht Abhängigkeiten im Datenmodell deutlich Jeder Entwickler braucht eine Datenbank

19 19 Testdaten automtatisch: Jeder Testfall erzeugt alle benötigten Daten schnell: leere Datenbank einfach: Bei Bedarf Refactoring gemeinsam genutzte Testdatenerzeugung automtatisch: Jeder Testfall erzeugt alle benötigten Daten schnell: leere Datenbank einfach: Bei Bedarf Refactoring gemeinsam genutzte Testdatenerzeugung

20 20 Übersicht Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB static und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB static und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion

21 21 static ist böse statischer Zustand ist problematisch schlechte Wiederverwendbarkeit keine unabhängige Testkonfiguration implizite Querabhängigkeiten von Tests statischer Code ist okay statischer Zustand ist problematisch schlechte Wiederverwendbarkeit keine unabhängige Testkonfiguration implizite Querabhängigkeiten von Tests statischer Code ist okay

22 22 Factories Nur auf den ersten Blick harmlos kapseln verwendete Implementierung Problem ist nicht die Factory selbst sondern verwendender Code alle Nachteile von statischen Daten Singletons sind problematisch auch JNDI zusätzliche Indirektionsstufen ändern nichts... Nur auf den ersten Blick harmlos kapseln verwendete Implementierung Problem ist nicht die Factory selbst sondern verwendender Code alle Nachteile von statischen Daten Singletons sind problematisch auch JNDI zusätzliche Indirektionsstufen ändern nichts...

23 23 Konfigurationsdaten zentrale Stelle für Konfigurationen Properties, Servletparameter, EJB-Parameter,... per definitionen globale Daten, d.h. static Versuchung, sie public static bekannt zu machen Alternative: Code mit Konfigurationsobjekt parametrieren! zentrale Stelle für Konfigurationen Properties, Servletparameter, EJB-Parameter,... per definitionen globale Daten, d.h. static Versuchung, sie public static bekannt zu machen Alternative: Code mit Konfigurationsobjekt parametrieren!

24 24 Auswirkungen auf das Design Lego-Baukasten sehr flexibel oft wiederverwendbar separat testbare Systemteile dynamisch konfiguriert Gefahr, dass unzusammenhängend und dadurch kompliziert (Ravioli) Refactoring Lego-Baukasten sehr flexibel oft wiederverwendbar separat testbare Systemteile dynamisch konfiguriert Gefahr, dass unzusammenhängend und dadurch kompliziert (Ravioli) Refactoring

25 25 Tests auf Systemebene Zusammenhang durch Gesamttest Black Box Konkrete Integration des Zielsystems testen Es gibt andere Arten, Systeme zu entwerfen Aber mit geringerer Testabdeckung Zusammenhang durch Gesamttest Black Box Konkrete Integration des Zielsystems testen Es gibt andere Arten, Systeme zu entwerfen Aber mit geringerer Testabdeckung

26 26 Übersicht Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB static und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB static und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion

27 27 EJBs leben im Container... Vorteile: Infrastruktur: JNDI, Transaktionen,... Erzwungene Trennung von Schnittstelle und Implementierung Aber durch Nachteile erkauft: nur im Container lauffähig Deployment kostet Zeit Deskriptoren legen Implementierungen fest Schwerer zu Debuggen Vorteile: Infrastruktur: JNDI, Transaktionen,... Erzwungene Trennung von Schnittstelle und Implementierung Aber durch Nachteile erkauft: nur im Container lauffähig Deployment kostet Zeit Deskriptoren legen Implementierungen fest Schwerer zu Debuggen

28 und ihre Tests? Brute Force: Deployment und Debugger nicht automatisch, nicht regressionsfähig je nach IDE zeitaufwändig Black Box-Tests: Testen der deployten Software mit JUnit Lange Testzyklen schlechte Abdeckung keine Mock Objects Brute Force: Deployment und Debugger nicht automatisch, nicht regressionsfähig je nach IDE zeitaufwändig Black Box-Tests: Testen der deployten Software mit JUnit Lange Testzyklen schlechte Abdeckung keine Mock Objects

29 29 Ziel: separat testen Komponenten-Gedanke: getrennt entwickelbar frei kombinierbar Praktische Probleme: Konfigurations-Parameter JNDI DataSource... Komponenten-Gedanke: getrennt entwickelbar frei kombinierbar Praktische Probleme: Konfigurations-Parameter JNDI DataSource...

30 30 Delegate Logik in separate Klasse auslagern, EJB delegiert Interaktion mit App-Server nur in EJB Delegate ist lauf- und testfähig ohne Container EJB beliefert Logik in separate Klasse auslagern, EJB delegiert Interaktion mit App-Server nur in EJB Delegate ist lauf- und testfähig ohne Container EJB beliefert XyzBeanXyzDelegate JNDI etc.

31 31 Business Interface Business Interface mit den fachlichen Methoden Remote-Interface erbt vom fachlichen Interface fremder Delegate kann vom BI abhängen Business Interface mit den fachlichen Methoden Remote-Interface erbt vom fachlichen Interface fremder Delegate kann vom BI abhängen XyzBI XyzRemote EJBObject AbcBean AbcDelegate

32 32 z.B. Begrüßungsservice Begrüßungs-EJB holt den Namen von Kundenmanager-EJB KundenMgrBean KundenMgrBI BegruesserBean BegruesserDelegate KundenMgrRemote KundenMgrHome

33 33 Praktisches Beispiel Ein Quelltext sagt mehr als tausend Folien...

34 34 Was ist passiert? Business Interface fachliche Schnittstelle der EJB Delegate unabhängig vom Container kennt andere EJBs als Business Interface JUnit-Test für Delegate Mock-Implementierungen für andere EJBs / Business Interfaces Business Interface fachliche Schnittstelle der EJB Delegate unabhängig vom Container kennt andere EJBs als Business Interface JUnit-Test für Delegate Mock-Implementierungen für andere EJBs / Business Interfaces

35 35 Übersicht Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB static und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB static und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion

36 36 Mock Objects Abhängigkeiten zwischen Klassen erschweren das Testen. Abhängigkeiten auflösen durch Interfaces Test-Code verwendet spezielle Test- Implementierungen Kapselung von Programmgrenzen Abhängigkeiten zwischen Klassen erschweren das Testen. Abhängigkeiten auflösen durch Interfaces Test-Code verwendet spezielle Test- Implementierungen Kapselung von Programmgrenzen

37 37 EJBs implizite Abhängigkeiten vom Container (JNDI, Parameter,...) von anderen EJBs separate Implementierung, EJB als dünner Wrapper reicht Aufrufe durch Business Interface als Schnittstelle ohne technische Methoden implizite Abhängigkeiten vom Container (JNDI, Parameter,...) von anderen EJBs separate Implementierung, EJB als dünner Wrapper reicht Aufrufe durch Business Interface als Schnittstelle ohne technische Methoden

38 38 Los geht´s Es gibt nichts Gutes außer man tut es gute Testabdeckung ist möglich Es lohnt sich Testen macht Spaß Refactoring Es gibt nichts Gutes außer man tut es gute Testabdeckung ist möglich Es lohnt sich Testen macht Spaß Refactoring

39 39 Literatur Dependency Inversion: /articles/dip.pdf Testen von EJBs ohne Application Server, Java Magazin 10/02 Dependency Inversion: /articles/dip.pdf Testen von EJBs ohne Application Server, Java Magazin 10/02

40 40 Übersicht Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB static und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB static und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion


Herunterladen ppt "JUnit für Fortgeschrittene"

Ähnliche Präsentationen


Google-Anzeigen