Pruebas Unitarias Dirigidas por Datos

Question

¿Cuál es la mejor práctica para probar una API que depende de los datos de la base de datos? ¿Cuáles son los problemas que debo tener en cuenta en un entorno de "Integración continua" que ejecuta pruebas unitarias como parte del proceso de compilación? Quiero decir, ¿desplegarías tu base de datos como parte de los scripts de compilación (puede ejecutar tu instalador) o deberías buscar datos codificados [usa pruebas de unidades controladas por datos de MSTest con XML]?

entiendo que puedo burlarse de la capa de datos para la capa de lógica de negocios, pero lo que si tuviera problemas en mis instrucciones SQL en DAL? Necesito golpear la base de datos, ¿verdad?

Bueno ... eso es un torrente de preguntas:) ... Pensamientos?

Answer 1

medida de lo posible que se burle a cabo código para evitar golpear la base de datos por completo, pero me parece que tienes razón acerca de la necesidad de probar su SQL en algún lugar a lo largo de la línea. Si escribe pruebas que llegan a la base de datos, un consejo clave para evitar dolores de cabeza es asegurarse de que su configuración obtenga los datos en un estado conocido, en lugar de confiar en que ya hay datos adecuados disponibles.

Y, por supuesto, ¡nunca haga una prueba en su base de datos en vivo! Pero no hace falta decirlo :)

Answer 2

Una cosa que hice fue crear métodos estáticos que devuelven datos de prueba de un estado conocido. Luego utilizaría un DAL "falso" para devolver estos datos como si realmente estuviera llamando a la base de datos. En cuanto a probar el procedimiento sql/almacenado, lo probé usando SQL Management Studio. YMMV!

Answer 3

Es una buena idea limpiar automáticamente la base de datos de prueba y luego rellenarlo con los datos de instrumento de prueba que serán asumidos para estar allí para todas las pruebas que necesitan conectarse a la base de datos. La base de datos debe restablecerse antes de cada prueba para su aislamiento adecuado: una prueba fallida que incluya datos incorrectos podría provocar falsos fallos en las pruebas siguientes y se complica si debe ejecutar las pruebas en un orden determinado para obtener resultados consistentes.

Puede borrar y completar la base de datos con herramientas (DBUnit, DBUnit.NET, otras) o simplemente crear sus propias clases de utilidad para hacer lo mismo.

Como usted ha dicho, otras capas deberían estar lo suficientemente desacopladas de las clases que realmente afectó a la base de datos, por lo que la necesidad de cualquier tipo de base de datos que participan en los ensayos se limita a las pruebas se ejecutan una pequeña parte de su código base. Los componentes que acceden a la base de datos se pueden burlar/troquelar para todo lo que dependa de ellos.

Answer 4

Como se ha mencionado, el uso burla para simular DB llama en las pruebas de unidad a menos que quiera jugar con sus pruebas y datos sin fin. Probar las declaraciones SQL implica más de integration test. Ejecute esa prueba separada de la unidad, son 2 bestias diferentes.