2010-09-15 17 views
7

Estoy trabajando en una aplicación Java EE 6. Cuando comencé, estaba escribiendo pruebas para mis clases EJB instanciando manualmente el EJB, luego agregando manualmente los miembros que normalmente son proporcionados por la inyección de dependencia. A medida que la aplicación se vuelve más complicada, me parece que este enfoque simplemente no lo corta. Así que me gustaría poder iniciar mi propio contenedor EJB en el marco de prueba, para que pueda administrar mis beans. ¿Cuál es la mejor manera de abordar esto? He oído hablar de javax.ejb.embeddable.EJBContainer, ¿hay otras opciones?Estrategias de prueba EJB?

(estoy usando Glassfish 3, y la construcción con Maven, si hay alguna diferencia.)

Respuesta

2

¿Qué estás probando exactamente? ¿Lógica? ¿Configuración? ¿NECESITA probar las clases de EJB directamente? ¿Sería suficiente para sus pruebas comportarse como un cliente EJB contra un contenedor en ejecución? (Recuerde que no hay ninguna regla que diga que las pruebas automatizadas de unidades no pueden requerir un sistema bajo prueba).

Si es necesario probar la lógica comercial, mueva ese código a POJO y realice pruebas normalmente; no sería necesario probar los POJO que se ejecutan en un contenedor, ya que el contenedor no debería afectar la lógica comercial.

En una situación relacionada, nunca he probado JUnit directamente una clase de servlet o una clase de controlador Struts. Definitivamente pruebo los POJO de los que dependen, y pruebo la aplicación final (ejecutándose en un contenedor de servlets, probado con HtmlUnit), suponiendo que si la aplicación final funciona, entonces la plomería también funciona.

+0

Obviamente, probar POJOs es más fácil. Pero no puedo sacar toda la lógica de mis EJB y convertirla en clases independientes; si pudiera hacerlo, no estaría utilizando EJB en primer lugar. Actuar como un cliente EJB contra un contenedor en ejecución es una buena descripción de lo que estoy tratando de hacer, solo estoy tratando de encontrar la mejor manera de lograrlo. –

+0

Creo que tenía razón al probar la aplicación implementada. Intenté que EJBContainer funcionara para mí (utilizando glassfish-embedded como implementación), pasé por muchos aros para hacer funcionar la persistencia, y finalmente renuncié cuando me di cuenta de que un servicio de temporizador EJB (del que depende mi aplicación en varios lugares) no fue provisto Me di cuenta de que incluso si lograba armar algún tipo de motor para ejecutar mis EJB, nunca replicaría TODAS las condiciones dentro de un contenedor real, por lo que sería una prueba inútil. –

+4

'Recuerde que no hay ninguna regla que diga que las pruebas automatizadas de unidades no pueden requerir un sistema bajo prueba en ejecución. Bueno, en realidad, hay reglas y dichas pruebas no son pruebas unitarias, por definición :) –

0

No estoy del todo seguro de si eso ayuda a su caso, pero echar un vistazo a Smokestack. Personalmente no trabajo en el espacio de EE (fuera de las especificaciones de Servlet), pero vi una presentación sobre esto en un momento dado y parece que puede hacer lo que necesita.

2

He oído hablar de javax.ejb.embeddable.EJBContainer, ¿hay otras opciones?

La API EJBContainer es una opción. El otro sería usar Arquillian (y SchrinkWrap).

Algunos más enlaces:

+0

Arquillian se ve muy bien, pero no parece proporcionar un servicio de temporizador EJB, por lo que en mi caso, tendría una utilidad limitada. También vea mi respuesta a Rodney. –

+0

@Mike ¿Estás * seguro * glassfish embedded no proporciona un servicio de temporizador EJB? AFAIK, glassfish embedded es un contenedor "real". –

+0

Parece que DEBE estar disponible, pero cuando lo estaba utilizando a través de la API EJBContainer, recibí un mensaje de error sobre el servicio del temporizador que no estaba disponible. No pude encontrar ninguna documentación relevante, excepto una breve publicación en el foro que dice que glassfish-embedded no tiene un servicio de temporizador. Puede haber una manera de hacerlo funcionar, pero no tengo tiempo para resolverlo, y puedo obtener lo que necesito de otras maneras. –

0

Ahora hay Arquillian, los desarrolladores no deberían tener que ver alrededor de los contenedores Java EE incrustados nunca más.