JUnit für Fortgeschrittene

40
JUnit für Fortgeschrittene Arno.Haase@Haase- Consulting.com [email protected] www.Haase-Consulting.com

description

JUnit für Fortgeschrittene. [email protected] [email protected] www.Haase-Consulting.com. Übersicht. Einführung Mock Objects Programmgrenzen: I/O, Netzwerk, DB „static“ und andere Hindernisse EJBs unter freiem Himmel Zusammenfassung Fragen und Diskussion. - PowerPoint PPT Presentation

Transcript of JUnit für Fortgeschrittene

JUnit für Fortgeschrittene

[email protected]@acm.org

www.Haase-Consulting.com

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

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

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

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

Ü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

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

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

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

StatistikDatenquelle KundenStatistikDatenquelle

StatistikTest MockDatenquelle

10

Praktisches Beispiel

• Ein Quelltext sagt mehr als tausend Folien...• Ein Quelltext sagt mehr als tausend Folien...

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

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

Ü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

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

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

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

Client ServerCommunicator

HttpServCommNullServComm TimeoutServComm

ClientTest MockServComm

Netzwerk

17

Praktisches Beispiel

• Ein Quelltext sagt mehr als tausend Folien...• Ein Quelltext sagt mehr als tausend Folien...

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

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

Ü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

„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

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

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

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

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

Ü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

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

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

„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“

XyzBean XyzDelegate

JNDI etc.

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

z.B. Begrüßungsservice

• Begrüßungs-EJB holt den Namen von Kundenmanager-EJB

• Begrüßungs-EJB holt den Namen von Kundenmanager-EJB

KundenMgrBean

KundenMgrBI

BegruesserBean

BegruesserDelegate

KundenMgrRemote

KundenMgrHome

33

Praktisches Beispiel

• Ein Quelltext sagt mehr als tausend Folien...• Ein Quelltext sagt mehr als tausend Folien...

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

Ü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

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

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

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

Literatur

• http://www.mockobjects.com

• http://www.easymock.org

• Dependency Inversion: http://www.objectmentor.com/resources/articles/dip.pdf

• „Testen von EJBs ohne Application Server“, Java Magazin 10/02

• http://www.mockobjects.com

• http://www.easymock.org

• Dependency Inversion: http://www.objectmentor.com/resources/articles/dip.pdf

• „Testen von EJBs ohne Application Server“, Java Magazin 10/02

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