Escribir pruebas para DAO

Question

Actualmente estoy asignado a escribir una prueba para un proyecto, ¿es necesario escribir pruebas para las clases DAO?

Answer 1

Depende :-)

Si sus clases DAO sólo contienen el código necesario para traer las entidades de la base de datos, es mejor ponerlos a prueba en las pruebas de integración separados *. El código que se probará en la unidad es la "lógica de negocios" que puede probar de forma unitaria utilizando DAO simulados.

[Actualización] E.g. con EasyMock puede configurar fácilmente un simulacro para una clase específica (con su extensión de clase, incluso se pueden burlar clases concretas), configurarlo para devolver un objeto específico de una determinada llamada de método e inyectarlo en su clase para probarlo.

Parece que el sitio web de EasyMock ya no funciona, espero que vuelva pronto. Luego, puede consultar la documentación, que en mi humilde opinión es bastante clara y exhaustiva, con muchos ejemplos de código. Sin muchos detalles en su pregunta, no puedo dar una respuesta más concreta. [/ Actualización]

Si, otoh, los DAOs contienen también la lógica de negocio, su mejor opción - si se puede hacer que - sería refactorizar ellos y seguir la lógica de negocio de DAO, a continuación, se puede aplicar el estrategia anterior.

Pero la conclusión es, siempre tenga en cuenta el lema de prueba de la unidad "probar todo lo que podría romperse". En otras palabras, debemos priorizar nuestras tareas y concentrar nuestros esfuerzos en escribir las pruebas que proporcionan el mayor beneficio con el menor esfuerzo. Primero, escriba pruebas unitarias para las piezas de código más críticas y con mayor riesgo de errores. El código que, en su opinión, es tan simple que posiblemente no se puede romper está más abajo en la lista. Por supuesto, es aconsejable consultar con desarrolladores experimentados sobre piezas concretas de código: es posible que conozcan y detecten posibles trampas y problemas de los que usted no es consciente.

* se supone que las pruebas de unidad son livianas, rápidas y aisladas del entorno tanto como sea posible. Por lo tanto, las pruebas que incluyen llamadas a un DB real no son pruebas unitarias sino pruebas de integración. Aunque técnicamente pueden construirse y ejecutarse con JUnit (y por ejemplo, DbUnit), son mucho más complejas y órdenes de magnitud más lentas que las pruebas de unidades genuinas. A veces esto los hace inadecuados para ser ejecutados después de cada pequeño cambio de código, ya que las pruebas de unidades regulares podrían (y con frecuencia deberían) ser utilizadas.

Answer 2

Sí, debe escribir pruebas de unidad para DAO.

Estas pruebas unitarias pueden usar una base de datos en memoria. Véase, por ejemplo: HyperSQL

artículo sobre el uso de HyperSQL para escribir pruebas de unidad de persistencia en Java:

http://www.mikebosch.com/?p=8

Answer 3

No es necesario escribir pruebas para nada. ¿Tiene obtener beneficio de escribir pruebas para sus clases DAO? Probablemente.

Answer 4

Sí. Pero pocas personas dirían eso, no entra en la categoría de pruebas unitarias. Porque no se ajustará a la definición de prueba unitaria por decir. Lo llamamos prueba de integración donde probamos la integración del código a la base de datos.

Además, estoy de acuerdo con la idea de Bruno aquí.Además, hay API disponibles para hacer eso, una es DBUnit.

Answer 5

Sí. Hay varios beneficios de hacerlo. Una vez que esté seguro de que su capa DAO funciona bien, la reparación de defectos en etapas posteriores se vuelve fácil.

Answer 6

Argumentaría que deberíamos escribir pruebas unitarias para DAO y uno de los mayores desafíos para hacerlo es la configuración y limpieza de datos de prueba. Ahí es donde creo que los marcos, como Spring JDBC testing framework, pueden ayudarnos al permitirnos controlar la transacción usando diferentes anotaciones [Ejemplo: @Rollback (true)].

Por ejemplo, si está probando una operación "crear/insertar", Spring le permite retrotraer completamente la transacción después de la ejecución del método de prueba, dejando siempre la base de datos en su estado original.

Usted puede echar un vistazo a este enlace para más información: Spring Testing

Esto puede ser aún más útil cuando, por sus pruebas de integración en el que no quiere una prueba a echar a perder la integridad de los datos, lo que puede causar otro prueba para fallar

Answer 7

El libro xUnit Test Patterns ofrece una gran cantidad de ideas excelentes sobre esta cuestión.