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.)
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. –
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. –
'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 :) –