Unit Testing EJB 3.1

7

Ich mache eine kleine Recherche über Unit Testing von EJB 3.1. Am Ende ist mein Ziel, eine einfach zu bedienende Lösung für Unit Testing EJB 3.1 zu erstellen.

  1. Ich habe nicht viel Wissen mit großen EJB-Implementierungen und daher möchte ich zuerst einige erfahrene Hände (Sie) bekommen, um Ihre Ideen zu bündeln, was in Unit Testing EJBs schwierig ist.
  2. Mit den ersten Recherchen, die ich bereits durchgeführt habe, kann ich die Vorteile der Verwendung von Mocking-Frameworks für Unit Testing verstehen, anstatt eingebettete Container zu verwenden. Obwohl beide gut sind, steht die Spottframetik etwas höher, wenn es um Unit Testing geht. Die eingebetteten Behälter sind natürlich sehr gut und haben ihre eigenen Vorteile, können jedoch eine andere Phase des Komponententestens sein. Ich bin immer noch der Meinung, dass es zumindest in einigen Szenarien Defizite geben sollte, wenn solche Rahmenbedingungen genutzt werden, die verbessert werden können.

Ich hoffe, ich könnte eine komplette Lösung für Unit Testing EJB machen, die ich in diesem Forum teilen kann, sobald sie fertig ist.

Danke für Ihre Unterstützung.

    
Bala 14.10.2011, 09:32
quelle

3 Antworten

14

Mein Rat an Sie wäre, nicht in die allgemeine Falle zu geraten, die ich sehe, nämlich zu denken, dass Sie zwischen einem Mocking und einem eingebetteten EJB-Container wählen müssen.

Sie können beide verwenden, Sie sollten beide verwenden, und wo Sie es schwierig finden, beide zu verwenden, sollten Sie eine bessere Unterstützung und mehr Funktionen von Ihrem EJB-Container verlangen.

Sicher werden Sie Leute bei OpenEJB wirklich unterstützend finden und mehr als glücklich, Eigenschaften hinzuzufügen, um das Beste beider Welten zu unterstützen. Fast alle wirklich guten Funktionen wurden um die Anfragen von Benutzern herum geschaffen, die versuchen, sehr spezifische Dinge zu tun und es schwer zu finden.

Standard EJBContainer API

%Vor%

Vollständige Quelle hier

Dadurch wird der Klassenpfad gescannt und alle Beans geladen.

Kein Scannen, einfacher Spottansatz

Ein etwas anderer Ansatz, bei dem Sie alles im Code definieren. Offensichtlich ist das Mocking einfacher, da Sie nach Bedarf Mock-Implementierungen von Beans bereitstellen können.

%Vor%

Full Quelle hier

Das Endergebnis

Es ist verlockend, sich auf die Unterschiede zwischen verschiedenen Arten von Tests usw. zu konzentrieren, aber für eine pragmatische Mitte gibt es sicherlich etwas zu sagen. Ich persönlich sehe nichts falsch daran, "Einheit" und "Integration" Stile so fließend wie möglich zu mischen.

Sicher, es ist ein bewundernswertes Ziel. Ideen und Feature-Anfragen, uns näher zu bringen, sind sehr willkommen.

    
David Blevins 16.10.2011, 03:43
quelle
5

Es gibt zwei verschiedene Arten von Tests, die Sie vielleicht in Erwägung ziehen (nicht exklusiv):

  • Komponententests : Ihre EJBs sind POJOs am ​​Ende des Tages und Sie können daher Ihr bevorzugtes Unit-Testing-Framework (z. B. JUnit) und ein spöttisches Framework wie Mockito oder EasyMock verwenden.
  • Integrationstest : Hier möchten Sie die EJBs so testen, als ob sie sich im Container befänden (nicht isoliert) und daher müssen Sie diesen Container irgendwie emulieren. Sie können Ihr Einheitentestframework immer noch zum Codieren Ihrer Tests verwenden (z. B. JUnit), aber jetzt testen Sie, wie sich diese EJBs im Container verhalten und mit anderen Kollaborateuren (z. B. anderen EJBs) interagieren. Dafür würde ich Arquillian empfehlen
Gonzalo Garcia Lasurtegui 18.10.2011 12:46
quelle
3

Sie können Needle für Komponententests von Java EE-Komponenten verwenden.

Needle ist ein einfaches Framework zum Testen von Java EE-Komponenten außerhalb des Containers. Es reduziert den Test-Setup-Code, indem Abhängigkeiten analysiert und Mock-Objekte automatisch injiziert werden.

Ссылка

    
Heinz 28.10.2012 20:27
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Neuer Fehler in iOS 5: WebKit hat eine nicht abgefangene Ausnahme verworfen