EJB-Teststrategien?

Ich arbeite an einer Java EE 6-Anwendung. Als ich anfing, schrieb ich Tests für meine EJB-Klassen, indem ich das EJB manuell instantiierte und dann manuell die Mitglieder hinzufügte, die normalerweise durch die Abhängigkeitsinjektion bereitgestellt werden. Als die Anwendung komplizierter wird, finde ich, dass dieser Ansatz es nicht einfach macht. Daher möchte ich meinen eigenen EJB-Container im Testframework starten können, damit er meine Beans verwalten kann. Was ist der beste Weg, um dies zu erreichen? Ich habe von javax.ejb.embeddable.EJBContainer gehört, gibt es andere Optionen?EJB-Teststrategien?

(Ich bin mit Glassfish 3 und Gebäuden mit Maven, wenn das einen Unterschied macht.)

Quelle

2010-09-15 Mike Baranczak

Was genau testen Sie? Logik? Aufbau? Müssen Sie die EJB-Klassen direkt testen? Wäre es ausreichend, wenn sich Ihre Tests wie ein EJB-Client gegen einen laufenden Container verhalten würden? (Denken Sie daran, dass keine Regel besagt, dass automatisierte Komponententests kein laufendes System erfordern.)

Wenn es Geschäftslogik ist, die Sie testen müssen, verschieben Sie diesen Code in POJOs und testen Sie normal; Sie müssten dann die POJOs, die in einem Container ausgeführt werden, nicht testen, da der Container die Geschäftslogik nicht beeinträchtigen sollte.

In einer verwandten Situation habe ich nie direkt eine JUnit-Servlet-Klasse oder eine Struts-Controller-Klasse getestet. Ich prüfe definitiv die POJOs, von denen die abhängig sind, und ich teste die Endanwendung (läuft in einem Servlet-Container, getestet mit HtmlUnit), vorausgesetzt, dass, wenn die End-App funktioniert, auch die Installation funktioniert.

Quelle

2010-09-15 20:54:59

Offensichtlich ist das Testen von POJOs einfacher. Aber ich kann nicht die ganze Logik aus meinen EJBs in freistehende Klassen verschieben - wenn ich das tun könnte, würde ich überhaupt keine EJBs benutzen. Als EJB-Client gegen einen laufenden Container zu agieren, ist eine gute Beschreibung dessen, was ich versuche zu tun. Ich versuche nur, den besten Weg herauszufinden, dies zu erreichen. –

Ich denke, Sie hatten Recht, die bereitgestellte Anwendung zu testen. Ich habe versucht, EJBContainer für mich arbeiten zu lassen (mit glassfish-embedded als Implementierung), bin durch viele Reifen gesprungen, um Ausdauerarbeit zu leisten, und habe dann endlich aufgehört, als ich merkte, dass ein EJB-Timer-Dienst (an dem meine App hängt) wurde nicht zur Verfügung gestellt. Ich erkannte, dass selbst wenn es mir gelingen würde, eine Art Engine für meine EJBs einzurichten, sie würde niemals ALLE Bedingungen in einem echten Container replizieren, also wäre es ein nutzloser Test. –

'Denken Sie daran, es gibt keine Regel, die besagt, dass automatisierte Komponententests kein laufendes System erfordern können. Nun, eigentlich gibt es Regeln und solche Tests sind keine Komponententests, per Definition :) –

Ich bin nicht ganz sicher, ob das Ihren Fall hilft, aber einen Blick auf Smokestack. Ich persönlich arbeite nicht im EE-Bereich (außerhalb der Servlet-Spezifikation), aber ich habe eine Präsentation darüber gesehen und sieht aus, als könnte sie tun, was Sie brauchen.

Quelle

2010-09-15 20:32:04 whaley

Ich habe von javax.ejb.embeddable.EJBContainer gehört, gibt es andere Optionen?

Die EJBContainer API ist eine Option. Der andere wäre Arquillian (und SchrinkWrap) zu verwenden.

Einige weitere Links:

Quelle

2010-09-15 23:34:53

Arquillian sieht ziemlich gut aus, aber es scheint keinen EJB-Timer-Dienst zu bieten, also hätte es in meinem Fall nur begrenzten Nutzen. Siehe auch meine Antwort auf Rodney. –

@Mike Sind Sie * sicher * Glassfish Embedded bietet keinen EJB-Timer-Service? AFAIK, Glassfish Embedded ist ein "echter" Container. –

Es scheint so, als ob es verfügbar sein sollte, aber als ich es über die EJBContainer API benutzte, bekam ich eine Fehlermeldung über den nicht verfügbaren Zeitgeberdienst. Ich konnte keine relevante Dokumentation finden, außer einem kurzen Beitrag im Forum, der besagt, dass glassfish-embedded keinen Timer-Dienst hat. Es mag einen Weg geben, damit es funktioniert, aber ich habe keine Zeit, es herauszufinden, und ich kann bekommen, was ich auf andere Weise brauche. –

Jetzt gibt es Arquillian, Entwickler sollten nicht eingebettete Java EE-Container hantieren mit brauchen nicht mehr.

Quelle

2014-01-24 02:08:40

Antwort

Verwandte Themen