Auschecken orderMngr.domain.customer.CustomerTest in der "jmockit/samples/orderMngmntWebapp" Beispieltestsuite, die in der JMockit-Volldistribution gefunden wird. Diese Testklasse basiert auf der Hibernate-Emulation. Es kann über das Ziel "sampleTests" in "jmockit/build.xml" ausgeführt werden.
Meine Motivation für die Erstellung dieses Tools war hauptsächlich, dass die Erstellung von SessionFactory zu lange dauert, wenn das Projekt Hunderte von zugeordneten Entitäten enthält. (Es dauerte etwa 20-30 Sekunden in einem Projekt mit mehr als 400 Entity-Klassen.) Dies in einer Suite von Integrationstests natürlich. Für eine Reihe von Komponententests ist dieses Tool nicht nützlich.
Die Idee war, dass ein Entwickler die Integrationstests in einer lokalen Entwicklungsumgebung schnell ausführen konnte, um Geschäftslogik, aber nicht Persistenz zu testen, während der automatisierte Build-Server die gesamte Testsuite ohne Emulation regelmäßig ausführen ließ.
Beachten Sie, dass HQL-Abfragen bei der Verwendung der Hibernate-Emulation weiterhin getestet werden. Die Fake-Implementierung analysiert HQL-Strings und führt die Abfrage gegen Entity-Instanzen aus, die im Speicher "persistent" sind. O/R-Zuordnungsinformationen werden jedoch ignoriert.
Mocking DAOs ist auch perfekt gültig, aber Ihre Tests werden nie wirklich das O/R-Mapping, HQL-Abfragen oder tatsächlichen Datenbankzugriff testen. Wenn Sie die Hibernate-Emulation verwenden, erstellen Sie keine Mocks, können die Tests jedoch über eine gefälschte Hibernate-Implementierung ausführen, die eine ähnliche In-Memory-Datenbank bietet.
hmm interessant, hat niemand versucht, es vorher zu verwenden? –