java - arquillian - Mejores prácticas de JUnit Test basadas en JPA

maven-2 testng

Question

Esta es una pregunta un tanto extraña, pero me ha estado molestando durante algunos meses. He creado una aplicación web basada en JPA usando Wicket + Hibernate (construido con Maven), y quiero probar la capa DAO directamente. Creé un archivo src / test / resources / META-INF / persistence.xml específico que utilicé para probar, pero he tenido conflictos con WTP y similares. Para evitar estos problemas, creé un proyecto de prueba separado donde las pruebas de la unidad en vivo. ¿Existe una mejor manera de administrar las pruebas unitarias para un proyecto JPA sin tener duelos entre los archivos de persistencia?

Adición: ¿Serían más fáciles otros marcos de prueba (TestNG, por ejemplo)?

Answer 1

Como se menciona aquí: http://www.devx.com/java/Article/36785/1954 , puede eliminar las siguientes líneas del .settings/org.eclipse.wst.common.component de su proyecto para evitar la implementación de recursos de prueba con el Aplicación Web.

<wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/java"/>
<wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/resources"/>

Answer 2

Es posible que desee probar mockito . La prueba funciona así:

Usas mockito para "implementar" EntityManager . En lugar del código real, usa los métodos de mockito para decir "si la aplicación llama a getReference() , luego devuelve este objeto". En segundo plano, mockito creará una instancia proxy que interceptará las llamadas al método Java y devolverá los valores que especifique. Las llamadas a otros métodos devolverán null .

createQuery() cosas como createQuery() funciona de la misma manera, pero primero debe crear una maqueta de Query y luego usar el mismo enfoque que en getReference() (devolver la maqueta de consulta).

Como no usa un EM real, no necesita un persistence.xml real.

Una solución mucho más simple sería si pudiera establecer alguna propiedad para cambiar el nombre del archivo persistence.xml , pero no creo que esto sea posible.

Algunos otros enlaces que pueden ayudar:

• Cómo configurar JPA para probar en Maven
• Sugerir un marco de prueba de unidad JPA

Answer 3

Usamos archivos persistence.xml duales para producción y tiempos de ejecución de prueba, pero solo es un problema relacionado con classpath (utilizamos Eclipse pero no confiamos mucho en los plugins WTP). La única diferencia entre los dos es que la versión de producción no contiene definiciones de entidad.

No usamos un marco de burla para probar JPA ya que esto no agregaría ningún valor a nuestras pruebas. Las pruebas sí ejecutan acceso a datos reales con JPA que habla con la base de datos PostgreSQL.

Nuestro enfoque de las pruebas se basa en el marco de prueba de Spring para la capa de persistencia: prueba en la transacción. Nuestra aplicación está basada en Spring, pero este enfoque es igualmente útil para aplicaciones arbitrarias que quieran aprovechar las clases de prueba de Spring. La esencia es que cada prueba se ejecuta dentro de una única transacción que nunca se compromete y al final (en tearDown) se revierte automáticamente. Esto resuelve el problema de la contaminación de datos y la dependencia de prueba de una manera muy agradable, discreta y transparente.

El marco de prueba de Spring es flexible para permitir las pruebas de transacciones múltiples, pero estos son casos especiales que constituyen no más del 10% de las pruebas.

Todavía usamos soporte heredado para JUnit 3.8 pero el nuevo Spring TestContext Framework para JUnit 4 parece muy atractivo.

Para configurar datos de prueba dentro de la transacción, usamos una clase de utilidad interna que construye entidades comerciales. Dado que se comparte entre todas las pruebas, la sobrecarga para mantenerla y admitirla es muy superior a los beneficios de contar con una manera estándar y confiable de configurar los datos de prueba.

Spring DI ayuda a que las pruebas sean concisas y autodescriptivas, pero no es una característica crítica.

Answer 4

Usar las pruebas unitarias de Spring y Spring es la mejor manera de hacerlo. Con Spring, no necesita dos persistence.xml ya que su persistence.xml no tiene nada, todo está especificado para la primavera (todo lo que especificamos en nuestra persistence.xml es el nombre de la unidad de persistencia) y por lo tanto puede cambiar la configuración de la base de datos etc. con primavera.

Y como señaló Topchef, las pruebas de unidades basadas en transacciones de Spring son geniales.