DAO - Mock Objekte

[kama]

Hallo,

ich habe da mal eine Frage Unit Tests und Mock Objekte betreffend.

Ich habe ein DAO mit entsprechenden Methoden, die aus einer Datenbank entsprechende Ergebenisse liefern.

Jetzt möchte ich einen Unit Test schreiben, der OHNE die Datenbank funktioniert.
Meine Vorstellung ist jetzt, die DAO Schicht mit einer Mock Schicht zu ersetzten und fixe ergebnisse zu liefern...

Die Frage ist, gibt es eine sinnvollere/geschicktere Vorgehensweise so etwas zu realiseren.

Es stellt sich auch für mich die Frage, wie man so etwas im Rahmen eines Builds (Ich nutze Maven 2) realisert ?

Bin für alle Hinweise etc. Dankbar...

MfG
Karl Heinz Marbaise

 

[maki]

Ich nutze JMock, andere bevorzugen EasyMock, imho besser als eigene Mocks schreiben.

Alternativen wären zB. DBUnit, zwar ist die DB ist dann immer noch Teil des Tests, aber man weiss vorher ganz genau welche Daten Drinnen sind, inkl. IDs.

 

[foobar]

Wenn dein DAO JPA/Hibernate verwendet kannste nach dem Test einfach ein Rollback machen, dann wird nichts persistiert und du hast immer einen konsistenten Datenbestand.
Ansonsten bietet es sich auch an Unittests in Groovy zu schreiben. Das ist wesentlicher einfacher als sich mit JMock und EasyMock rum zu ärgern.

 

[maki]

Wenn dein DAO JPA/Hibernate verwendet kannste nach dem Test einfach ein Rollback machen, dann wird nichts persistiert und du hast immer einen konsistenten Datenbestand.

Wenn die Transaktion durch ist, funzt kein Rollback mehr.
Wenn die Transaktion vorher abgebrochen wird und ein Rollback durchgeführt wird, hat man die Transaktion nicht getestet.

Ansonsten bietet es sich auch an Unittests in Groovy zu schreiben. Das ist wesentlicher einfacher als sich mit JMock und EasyMock rum zu ärgern.

Hab mich noch nie mit JMock geärgert, aber ob eine neue Sprache bzw. eine mehr im Projekt die bessere Lösung ist?

 

[kama]

Hallo,

zuerst einmal vielen dank für die schnellen Antworten....

Weiterhin muss ich sagen, dass ich dbUnit schon in anderen Bereichen einsetze, aber für diesen fall nichts ist, da ich hier explizit das Problem habe, dass die DB noch nicht vorhanden ist bzw. noch nicht mit sinnvollen werten gefüllt ist und ich zuerst einmal eine einfache Lösung in Form der Mocks überlegt habe, damit ich nicht den ganzen hantier mit Datenbank aufsetzen etc. mach muss...(ja auch embedded etc. oder h2 etc. wäre auch möglich; aber die muss ich ja auch initialisieren (DDL))....Derzeit bin ich halt in der Phase, dass ich noch keine Nutzbare DB habe, aber schon einiges fertig machen kann und muss....

Also die Hinweise zu easyMock und jMock waren schon sehr hilfreich.....

Die Frage zu Groovy wäre, würde mich das von der Problematik des ersetzens einer Schicht (in diesem Falle DAO) entbinden ? Ich vermute nicht....

Die Nächste Frage, die sich aus der Nutzung von xxxMock ergibt ist die, ob das im Zusammenhang mit einem Multimodule Projekt in Maven auch sinnvoll Nutzbar ist....

  root
    +--- DAO
    +--- WS
    +--- ...

Jetzt müsste ich für einen Test Teile des DAO's durch Mock's ersetzten so dass der Aufruf aus WS den DAO nutzt.. ?
Geht das bzw. hat das schon mal einer gemacht ?

Also es läuft im Endeffekt darauf hinaus, dass ich über die DAO's Daten liefern will, die aber aus eigener Quelle liefern will (Hard Coded für den Test), damit weiter oben liegende Schichten schon mal Testen kann.....

Vielen Dank.

MfG
Karl Heinz Marbaise

 

[byte]

Wenn dein DAO JPA/Hibernate verwendet kannste nach dem Test einfach ein Rollback machen, dann wird nichts persistiert und du hast immer einen konsistenten Datenbestand.

Wenn die Transaktion durch ist, funzt kein Rollback mehr.
Wenn die Transaktion vorher abgebrochen wird und ein Rollback durchgeführt wird, hat man die Transaktion nicht getestet.

Wir machen das genauso wie foobar beschrieben hat. Und mit Spring ist das auch denkbar einfach:

@TransactionConfiguration(defaultRollback=true)

Was ist schlecht daran? Immernoch besser, also mit Mock-Objekten die DB gar nicht zu testen, oder?

Jetzt müsste ich für einen Test Teile des DAO's durch Mock's ersetzten so dass der Aufruf aus WS den DAO nutzt.. ?
Geht das bzw. hat das schon mal einer gemacht ?

Spätestens hier ist Dependency Injection sehr sinnvoll. Du könntest dann einfach per Konfiguration die richtigen DAOs gegen Mock-Implementierungen austauschen, ohne den Code anzufassen.

 

[maki]

Jetzt müsste ich für einen Test Teile des DAO's durch Mock's ersetzten so dass der Aufruf aus WS den DAO nutzt.. ?
Geht das bzw. hat das schon mal einer gemacht ?

Hab letztens einen Artikel in der JavaSpektrum (nicht sicher ob die so heisst) gelesen, in dem das gezeigt wird, aber mit TestNG.
Im Prinzip werden unterschiedliche Initialisierungsmethoden für die Tests aufgerufen.

Was ist schlecht daran? Immernoch besser, also mit Mock-Objekten die DB gar nicht zu testen, oder?

Ja, foobar hat natürlich recht, hab ignoriert das die DB nicht getestet werden soll.

Allerdings haben Mockobjekte einige Vorteile, sie helfen bei Unittests enorm, egal ob DAOs oder andere Klassen getestet werden.
u.a. kann ich mit Mockobjekten sicherstellen, das Methoden aufgerufen werden und wie oft, auch sind sie wichtig um die Tests etc. unabhängig von einander und normalen Klassen zu haben, helfen bei der sog. "Interface Discovery" für TDD.

EasyMock und JMock beinflussen nicht den Buildprocess, egal ob von Maven ode Ant.

Ein Wort noch zu JMock, JMock1 war EasyMock unterlegen, deswegen lesen sich die Berichte alle zum Vorteil von EasyMock, ist aber spätesten mit JMock2 schon nicht mehr der Fall.

 

[kama]

Hallo,

erstmal vielen Dank für die Hinweise und Tipps....

Hab letztens einen Artikel in der JavaSpektrum (nicht sicher ob die so heisst) gelesen, in dem das gezeigt wird, aber mit TestNG. Im Prinzip werden unterschiedliche Initialisierungsmethoden für die Tests aufgerufen.

Könntest Du mal genau nachschauen wie das Teil heißt, da ich sowieso schon mit TestNG arbeite wäre das recht interessant?

EasyMock und JMock beinflussen nicht den Buildprocess, egal ob von Maven ode Ant.

Das Problem dabei ist, dass mein derzeitiger Build Prozess mit Maven schon eine ganze Menge sachen macht....Ich habe einen Integrations-Test, der ein WAR erzeugt, dass wird einen Tomcat deployed und dann dagegen Tests laufen läßt. Das bedeutet, dass hier schon sehr nah an der Wirklichkeit getestet wird....
Genau dass müsste ich jetzt ändern, damit die bisherigen Vorschläge realisert werden könnten....Somit ändert sich der Build Prozess garantiert....

Spätestens hier ist Dependency Injection sehr sinnvoll. Du könntest dann einfach per Konfiguration die richtigen DAOs gegen Mock-Implementierungen austauschen, ohne den Code anzufassen.

Ok. Das heißt mein bisheriges Design war nicht gut genug. Das muss ich also ändern, damit ich dann diese Änderung machen kann und eben das Gewünschte erreichen kann.....Wieder was gelernt...

MfG
Karl Heinz Marbaise

 

[foobar]

Ansonsten bietet es sich auch an Unittests in Groovy zu schreiben. Das ist wesentlicher einfacher als sich mit JMock und EasyMock rum zu ärgern.

Hab mich noch nie mit JMock geärgert, aber ob eine neue Sprache bzw. eine mehr im Projekt die bessere Lösung ist?

Mit ärgern meinte ich viel mehr die ziemlich schlecht lesbaren Mock-klassen. In Groovy gibt es eine native Syntax für Listen und Maps zusätzlich noch Closures. Damit kann man sich schnell eine beliebige Klasse erstellen Duck-Typing sei dank.

BTW im aktuellen Eclipsemagazin gibt es mehrere Artikel zum Thema Junit und JMock/Easymock.