2009-12-22 13 views
24

Quiero preguntar por su forma preferida de probar el código Java EE?¿Cómo se prueba el código Java EE?

He encontrado sólo tres proyectos, que están tratando de ayudar a las pruebas unitarias de código en Java EE ambiente:

Por eso me pregunto,

  • ¿Hay algún marco que ayude a escribir (j) la prueba unitaria para el código Java EE?
  • ¿utiliza servidores embebidos Java EE como jboss o glassfish v3?
  • ¿simula e inyecta usted mismo?

Muchas gracias ...

+0

Ver http://stackoverflow.com/questions/1733805/where-can-i-find-unod-unit-testing-resources-for-ejb-and-j2ee – ewernli

+0

Un proyecto obsoleto desactualizado: http: // sourceforge.net/projects/mockejb/ Última versión: 2004-09-04 – marabol

+1

Hay [este artículo] (http://www.oracle.com/technetwork/articles/java/unittesting-455385.html) de Adam Bien sobre la unidad probando para JavaEE desde 2011. –

Respuesta

24

Si por pruebas unitarias quiere decir ... la unidad de pruebas (pruebas de una unidad de aislamiento), entonces usted realmente no necesita ningún marco particular, ya que EJB3. 0 no son más que POJO anotados y, por lo tanto, pueden probarse con relativa facilidad sin ningún accesorio especial.

Ahora, si usted quiere decir algo más - como Pruebas de Integración o Pruebas funcionales - a continuación, , las herramientas pueden ayudar y simplificar las cosas (pero que realmente debe comenzar a utilizar la terminología correcta :) I' Asumiré que esto es lo que tienes en mente.

Primero, JUnitEE parece muerto y obsoleto y ni siquiera estoy seguro de que tenga algo para EJB3.x. En segundo lugar, no estoy impresionado por el Java EE 5 support de Cactus y tener que implementar pruebas de Cactus es doloroso (creo que Cactus era bueno para J2EE 1.4 pero ahora está un poco desactualizado). Así que esto nos deja con Ejb3Unit que es en mi opinión la mejor opción, especialmente si desea ejecutar fuera del contenedor pruebas, es decir, sin realmente implementar la aplicación (mucho más rápido).

Si desea ejecutar en las pruebas de contenedor, entonces podría utilizar un contenedor incrustado y mi preferencia actual es GlassFish v3, incluso para Java EE 5 (puedo estar equivocado, pero estoy bastante decepcionado por la hora de inicio de las últimas versiones de JBoss para que no me llame mucho la atención). Consulte la publicación GlassFish Embedded Reloaded, an appserver in your pocket para ver el código de muestra (que puede usar de sus pruebas) o Using maven plugin for v3 embedded glassfish (si usa maven).

Otra opción sería empaquetar e implementar su aplicación con Cargo y luego ejecutar algunas pruebas contra la aplicación implementada (con Selenium o una herramienta BDD, por ejemplo). Esto podría ser útil si desea ejecutar pruebas de extremo a extremo con un contenedor que no proporciona ninguna API incrustada.

Entonces, para responder a su última pregunta, usaría de hecho las herramientas disponibles, tal vez una combinación de ellas, para las pruebas que no son pruebas unitarias y no me burlaría/inyectaría cosas, excepto si no cubren algunas necesidades que no puedo pensar en este momento.

+0

Escuché que el proyecto Cactus ha vuelto a la vida con el nuevo desarrollador principal Petar Tahchiev. JSFUnit se basa en Cactus. – cetnar

+0

@cetnar ¡Oh, es bueno saberlo! De hecho, quizás estaba demasiado concentrado en EJB3 y olvidé por completo JSF. Muchas gracias por esta información. –

+0

Muchas gracias. Creo que crearé cunstructors para todos mis pojos EJB para permitir la inyección sin ningún reflejo. Cargo es interesante para la prueba de integración. ¡Gracias! – marabol

2

Como usted está interesado en pruebas unitarias, recomiendo JUnit. Puede probar los métodos en las clases principales. Si tiene dificultades para escribir casos de prueba unitaria utilizando JUnit, entonces probablemente el diseño no sea modular y esté muy acoplado. Primero, concéntrese en su funcionalidad principal y pruébela con JUnit.

2

He estado enfrentando el mismo problema de ejecutar pruebas de integración basadas en JUnit en un contenedor Java EE 6 (Glassfish v3, para ser precisos), y después de mucha navegación y búsqueda, no pude encontrar una solución que realmente se adaptaba a mis necesidades, así que escribí el mío, ahora publicado como jeeunit en Google Code.

No lo llamaría un marco de prueba, es solo un puñado de clases que proporcionan el pegamento entre JUnit y Embedded Glassfish.

La idea general es similar a Cactus, sus pruebas se ejecutan en el contenedor y son activadas por un servlet desde el exterior.

jeeunit es compatible con JUnit 4, Glassfish v3, CDI y genera los informes XML JUnit estándar como Ant o Maven Surefire (de hecho, reutilicé algún código de Ant para generar los informes).

1

Tenía un requisito para probar una aplicación CDI y escribí un corredor JUnit personalizado que ejecuta todo fuera del contenedor web.

http://jglue.org/cdi-unit/

Es adecuado para Java SE y también es compatible Solicitud ficticia, Sesión y Conversación ámbitos para aplicaciones de pruebas web.

Es pequeño y rápido, lo que es genial cuando tienes muchas pruebas de unidad.