Maven EAR Modul und EJB Abhängigkeiten Tests

Wir bauen unsere EAR & EJB Projekte mit Maven. Es wird alle EJB-Projekte erstellen und dann als die Abhängigkeit für EAR verwendet, so dass sie schließlich in die EAR-Datei gepackt werden.Maven EAR Modul und EJB Abhängigkeiten Tests

Das Problem ist, dass jedes EJB-Projekt Junit-Tests hat, die das EJB überprüfen. Vorläufig sind diese Tests nicht sehr nützlich, da sie versuchen, sich mit dem Anwendungsserver (jboss) zu verbinden und Methoden von der EJB-Schnittstelle auszuführen.

Gibt es eine Möglichkeit, die EJBs zu erstellen, erstellen und bereitstellen Sie die EAR und führen Sie dann alle Tests aus allen EJBs gegen den Anwendungsserver?

Momentan simuliere ich AP in Tests durch Initiierung von EJB-Implementierungsklassen und manuell "injizierende" Injektionen (someEJBImpl.em = EntityManager ....) was sehr ärgerlich ist, da wir zwischen ihnen sehr große Abhängigkeiten haben Ich muss mich selbst um Transaktionen kümmern.

Gibt es eine andere Möglichkeit, EJB-Tests gegen echte AP auszuführen? Kann EAR nach jedem EJB-Modul mit einer Teilmenge von EJB-Modulen, die bereits gebaut wurden, bereitgestellt werden? Aber wie ?

Kann eingestellt werden, um Maven-Tests aller EJB-Module als Teil von EAR-Tests auszuführen? Wie macht man das ?

Quelle

2009-07-27 m_vitaly

Dies ist kein einfaches Problem, und es gibt keine einfache Antwort. Hoffentlich helfen diese Hinweise.

Ich denke, Ihre beste Strategie besteht darin, Ihre Tests in echte Komponententests aufzuteilen - solche, die isoliert ohne einen Container laufen können und die Tests, die den Container erfordern, in Integrationstests verschieben.

Sie können Ejb3unit verwenden, um die Tests zu maximieren, für die kein Container ausgeführt werden muss. Es hilft, einige der komplizierten Abhängigkeiten zu verspotten. Ejb3unit hat ein Maven-Plugin, siehe documentation für Details zu ihrem Maven-Repository.

Andere spöttische Frameworks wie JMock können ebenfalls helfen. Sie können sowohl Klassen als auch Interfaces vortäuschen, wenn Sie eine ClassImposteriser verwenden.

Für die Tests, die einen EJB-Container benötigen, können Sie diese so konfigurieren, dass sie als integration tests ausgeführt werden. Je nach den Beziehungen zwischen Ihren EJB-Projekten kann es sinnvoll sein, sie in ein separates Projekt zu verschieben.

Es ist möglich, embedded Jetty instance in your JUnit tests zu starten und programmgesteuert Servlets hinzuzufügen. Natürlich ist Jetty kein EJB-Container, Sie benötigen einen EJB-Container wie OpenEJB.

Um OpenEJB in Jetty, verwenden Sie eine Konfiguration wie folgt konfiguriert werden:

<plugin> 
    <groupId>org.mortbay.jetty</groupId> 
    <artifactId>maven-jetty-plugin</artifactId> 
    <configuration> 
    <scanIntervalSeconds>5</scanIntervalSeconds> 
    <contextPath>/example</contextPath> 
    <systemProperties> 
     <systemProperty> 
     <name>java.naming.factory.initial</name> 
     <value>org.apache.openejb.client.LocalInitialContextFactory</value> 
     </systemProperty> 
     <systemProperty> 
     <name>java.naming.factory.url.pkgs</name> 
     <value>org.mortbay.naming</value> 
     </systemProperty> 
    </systemProperties> 
    </configuration> 
</plugin>

Die Abhängigkeits Erklärungen für OpenEJB wäre:

<dependency> 
    <groupId>org.apache.openejb</groupId> 
    <artifactId>openejb-core</artifactId> 
    <version>3.1</version> 
    <scope>test</scope> 
</dependency>

Sie auch Selenium zu helfen, mit den funktionellen Tests verwenden können (vorausgesetzt, dass Sie so weit gekommen sind), hier ist ein guide using Selenium, Jetty and OpenEJB zu tun.

Quelle

2009-07-27 05:15:53