¿Debo I Unit Test Data Layer Access? ¿Es esta una buena práctica y cómo hacerlo?

Question

Si tengo Data Access Layer (nHibernate), por ejemplo, una clase llamada UserProvider y una clase Business Logic UserBl, ¿debo probar sus métodos SaveUser o GetUserById, o cualquier otro método público en la capa DA que se llama desde BL? capa. ¿Es esto una redundancia o una práctica común para hacer?

¿Es común probar la capa DA de la unidad, o que pertenece al dominio de prueba de integración? ¿Es mejor tener una base de datos de prueba o crear datos de base de datos durante la prueba?

Cualquier ayuda es apreciada.

Answer 1

Es una buena práctica escribir pruebas unitarias para cada capa, incluso la DAL.

No creo que la ejecución de pruebas en el DB real sea una buena idea, puede arruinar datos importantes. Solíamos configurar una copia de la base de datos para pruebas con los datos suficientes para realizar pruebas. En nuestro proyecto de prueba, teníamos un archivo web.config especial con ajustes de prueba, como ConnectionString para nuestra prueba db.

Answer 2

No hay una respuesta correcta para esto, realmente depende. Algunas personas (por ejemplo, Roy Osherove) dicen que solo debe probar el código que tiene una lógica condicional (declaraciones IF, etc.), que puede incluir o no su DAL. Algunas personas (a menudo los que hacen TDD) dirán que debe probar todo, incluido el DAL, y aspirar a una cobertura de código del 100%.

Personalmente solo lo pruebo si tiene lógica, así que termine con algunos métodos DAL probados y otros no. La mayoría de las veces acabas comprobando que tu BL llama a tu DAL, lo cual tiene algún mérito pero no considero necesario. Creo que tiene más sentido tener pruebas de integración que cubran la aplicación de principio a fin, incluida la base de datos, que cubre cosas como GetUserById.

De cualquier manera, y probablemente ya lo sepa, pero asegúrese de que las pruebas de su unidad no toquen una base de datos real. (No hay problema para hacer esto, pero eso es una prueba de integración, no una prueba de unidad, ya que lleva mucho más tiempo e implica una configuración compleja, y debe ejecutarse por separado).

Answer 3

En mi experiencia, fue útil probar cada capa por sí mismo. Integrarlo y probar nuevamente. La prueba de integración normalmente no prueba todos los aspectos. A veces, si la capa de acceso a los datos (no sé nHibernate) se genera código o tipo de código genérico, parece excesivo. Pero he visto más de una vez que las pruebas sistemáticas dan sus frutos.

¿Es redundancia? En mi opinion, no es.

¿Es una práctica común? Difícil de decir. Yo diría que no. Lo he visto en algunos proyectos, pero no en todos los proyectos en los que trabajé. A menudo dependía del tiempo/recursos y la mentalidad del equipo/desarrollador individual.

¿Es mejor tener una base de datos de prueba o crear datos de base de datos durante la prueba? Esta es una pregunta bastante diferente. No se puede responder fácilmente. Depende de tu proyecto Crear uno nuevo es bueno, pero a veces arroja errores irreales (aunque los errores). Depende de su proyecto (desarrollo del producto o desarrollo propio). Por lo general, en un desarrollo propietario en el sitio, una base de datos se migra desde algún lugar. Por lo tanto, definitivamente se necesita una segunda prueba con los datos migrados. Pero esto es más bien a nivel de prueba del sistema.

Answer 4

Unidad de prueba de la DAL vale la pena como se ha mencionado si hay lógica en la que hay, por ejemplo, si se utiliza el mismo StoredProc para la inserción de actualización & su pena saber que funciona una inserción, una llamada posterior actualiza el anterior y un selecto lo devuelve y no una lista.En su caso SaveUser método probablemente se inserta por primera vez y posteriormente se actualiza, es bueno saber que esto es lo que se hace en la etapa de prueba de la unidad.

Si está utilizando un marco como iBatis o Hibernate donde puede implementar manejadores de tipo, vale la pena confirmar que los manejadores manejan los valores de una manera aceptable para su base de datos subyacente.

En cuanto a las pruebas contra un DB real si utiliza un marco como Spring, puede hacer uso de las clases de prueba de la unidad de base de datos con retrotracción automática de transacciones para ejecutar sus pruebas y el DB no se verá afectado posteriormente. Consulte here para obtener información. Otros probablemente ofrecen soporte similar.