unit-testing - when - mockito tutorial español
Unidad de pruebas DAO (5)
He estado buscando en EasyMock y tutoriales / ejemplos sobre cómo usarlo para las clases DAO de Pruebas Unitarias, para una prueba de "contenedor externo". Sin embargo, creo que la mayoría de ellos hablan de probar la capa de servicio en lugar de burlarse de la clase DAO. Estoy un poco confundido, ¿es realmente así como prueba de unidad la capa DAO?
Algunos dirían que las pruebas que interactúan con DB y EJB son en realidad pruebas de integración y no pruebas unitarias, pero entonces, ¿cómo sabría si su SQL es correcto (suponiendo que no hay ORM) y su DAO inserta / consulta los datos correctos de su real (lea, base de datos local que es similar a la de la base de datos de producción?
Leí que DBUnit es una solución para tal situación. Pero mi pregunta es sobre el uso de un marco como DBUnit "contenedor externo". ¿Qué pasa si el DAO depende de algunos EJB, cómo manejamos las transacciones, qué sucede si hay activadores que actualizan otras tablas en sus inserciones?
¿Cuál es la mejor manera de realizar una prueba unitaria solo de los DAO con estas dependencias?
Como complemento de las respuestas de Koya, puede usar HSQLDB para las pruebas DAO. Me imagino que tienes uso de Spring e Hibernate en tu proyecto. Necesitaría archivos de configuraciones por separado para señalar el HSQLDB, tendría que insertar datos antes de ejecutar las pruebas. Hay algunas limitaciones en lo que puede hacer con HSQLDB, pero está bien para uso general como consultas y combinaciones. Con esta solución se puede utilizar en un entorno continuo, como jenkins. Las pruebas de integración podrían utilizar el HSQLDB, por lo que esta parte no se burla.
Estoy usando HSQLDB para las pruebas de Dao y Service API. El rendimiento es bueno y soporta transacciones también. No estoy usando EJB. Yo uso Hibernate.
Hay algunos problemas que conozco que la ejecución de las pruebas en una base de datos diferente puede enmascarar algunos de los problemas de la base de datos compatibles. Pero creo que tales problemas deberían quedar atrapados en las pruebas de humo y aceptación.
Saludos, Koya
Finalmente decidí escribir las pruebas de la Unidad que pueden ejecutarse fuera del contenedor, con una base de datos activa y para el soporte transaccional utiliza un administrador de transacciones independiente (Bitronix), también puedo revertir. Supongo que esto todavía no hace que las pruebas de la Unidad Pura ... Me encantaría escuchar su opinión sobre este enfoque.
Personalmente, realizo una prueba unitaria de los DAO al acceder a algún tipo de base de datos de prueba, preferiblemente el mismo tipo de base de datos (obviamente, no la MISMA base de datos) que usa su aplicación en producción.
Creo que si haces eso, la prueba es más una prueba de integración, ya que depende de una base de datos en ejecución. Este enfoque tiene la ventaja de que está lo más cerca posible de su entorno de producción en ejecución. Tiene las desventajas de que necesita una configuración de prueba, necesita una base de datos de prueba en ejecución (ya sea local para su máquina o en algún lugar de su entorno) y las pruebas pueden tardar más en ejecutarse. También debe asegurarse de revertir los datos de prueba después de que se ejecuten las pruebas.
Una vez que se prueban los DAO, definitivamente simúltelos para probar en unidad sus servicios.
Por lo general, con los DAO, la idea es tener un envoltorio mínimo alrededor del código de acceso a los datos, por lo que no hay nada que probar, excepto el mapeo a la base de datos, y las pruebas unitarias con simulacros no sirven. Si realmente hay lógica en el DAO que vale la pena probar con simulacros, entonces se podría argumentar que está haciendo un mal uso del patrón DAO y que la lógica debería estar en un servicio.
Para probar la asignación a la base de datos DBUnit es útil porque le permite especificar un conjunto de datos de inicio antes de la prueba para que su prueba comience desde un estado conocido, y le permite especificar cuál debe ser el estado final de los datos, por lo que no No tenga que escribir un montón de código de prueba de unidad afirmando qué es lo que se espera.
Idealmente, si tiene una herramienta como Hibernate que abstrae la base de datos, puede utilizar una base de datos en memoria como H2 o HSQLDB, de modo que sus pruebas se ejecuten más rápido y no hay una base de datos para crear. Si tiene que usar una base de datos real, asegúrese de que sus pruebas se hagan para que puedan crear y eliminar datos sin afectar o ser impactados por otros procesos. En la práctica es poco probable tener una base de datos para usted mismo, tanto localmente como en entornos de CI, y el uso de la base de datos en memoria es mucho más práctico.