En TDD, ¿por qué OpenEJB y por qué Arquillian?

Question

Soy un desarrollador web y terminé en un desarrollo de Java EE (Richfaces, Seam 2, EJB 3.1, JPA). Para probar JPA, uso hipersónico y Mockito. Pero me falta conocimiento profundo de EJB.

Algunos pueden argumentar que debemos usar OpenEJB y Arquillian, pero ¿para qué? ¿Cuándo debo realizar pruebas dependientes del contenedor? ¿Cuáles son los posibles escenarios de prueba donde necesito OpenEJB y Arquillian?

favor ilumíneme :)

Answer 1

Hay dos aspectos en este caso.

1. Pruebas unitarias. Se pretende que sean muy rápidos (ejecute todo el conjunto de pruebas en segundos). Ponen a prueba trozos muy pequeños de tu código, es decir, un método. Para lograr este tipo de granularidad, debe burlarse de todo el entorno utilizando, por ejemplo, Mockito. Usted no está interesado en:
   • invocando EntityManager y poniendo entidades en la base de datos,
   • transacciones de prueba,
   • hacer invocaciones asíncronas,
   • golpear el punto final JMS, etc.

Se burla de todo este entorno y simplemente prueba cada método por separado. Las pruebas unitarias son de grano fino y sorprendentemente rápido. Es porque puedes ejecutarlos cada vez que realizas algunos cambios importantes en el código. Si fueran más complejos y llevaran mucho tiempo, el desarrollador no presionaría el botón de "prueba" tan a menudo como debería.

1. Integración prueba. Estos son más lentos, ya que desea probar la integración entre sus módulos. Que desea probar si 'hablan' entre sí adecuadamente, es decir:
   • son las transacciones que se propagan por la forma en que lo cuenta,
   • lo que sucede si se invoca el método de negocios con ninguna transacción en absoluto,
   • ¿Los cambios enviados por su cliente WebServices realmente afectan su método de punto final y agrega los datos a la base de datos?
   • ¿Qué ocurre si mi extremo de JMS arroja una ApplicationException? ¿Revertirá correctamente todos los cambios?

Como se ve, pruebas de integración son de grano grueso y a medida que se ejecutan en el contenedor (o básicamente: en el entorno de producción similar) que son mucho más lento. Normalmente, el desarrollador no ejecuta estas pruebas después de cada cambio de código.

Por supuesto, puede ejecutar el Contenedor EJB en modo incrustado, del mismo modo que puede ejecutar el JPA en Java SE. El punto es que el entorno artificial le brinda los servicios básicos, pero terminará con ajustes y aún así terminará con menos flexibilidad que en el contenedor real.

Arquillian le brinda la capacidad de crear el entorno de producción en el contenedor de su elección y simplemente ejecutar pruebas en este entorno (utilizando las fuentes de datos, los destinos JMS y muchas otras configuraciones que espera ver en el entorno de producción.)

Espero que ayude.

Answer 2

Asistí a Devoxx este año y tuve la oportunidad de responder a los usuarios de JBOSS esta pregunta. Algunos de los escenarios de prueba (las cosas me las arreglé para garabatear):

• de configuración del contenedor
• integración de contenedores
• límites de la transacción
• métodos de devolución de llamada Entidad
• Integración prueba
• Grabaciones de selenio