unit-testing - test - pruebas unitarias visual basic net
Pruebas unitarias basadas en datos (4)
Como se mencionó, utilice la burla para simular las llamadas a bases de datos en pruebas unitarias a menos que desee juguetear con sus pruebas y datos sin fin. La prueba de sentencias SQL implica más una prueba de integración . Ejecute esa prueba separada de la unidad, son 2 bestias diferentes.
¿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 simular la capa de datos para la capa de lógica de negocios, pero ¿qué sucede si tengo problemas en mis declaraciones SQL en DAL? Necesito golpear la base de datos, ¿verdad?
Bueno ... eso es un torrente de preguntas:) ... ¿Pensamientos?
En la medida de lo posible, debe burlar el código para evitar golpear la base de datos, pero me parece que tiene razón acerca de la necesidad de probar su SQL en algún momento. 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 pruebe contra su base de datos en vivo! Pero eso es evidente :)
Es una buena idea borrar automáticamente la base de datos de prueba y luego llenarla con datos de prueba de arnés que se asumirán que están ahí para todas las pruebas que necesitan conectarse a la base de datos. La base de datos debe restablecerse antes de cada prueba para un aislamiento adecuado: una prueba fallida que incluya datos incorrectos podría provocar falsos fallos en las pruebas posteriores 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 , otros) o simplemente crear sus propias clases de utilidad para hacer lo mismo.
Como dijiste, otras capas deberían estar lo suficientemente desacopladas de las clases que realmente golpean la base de datos, por lo que la necesidad de cualquier tipo de base de datos involucrada en las pruebas está limitada a las pruebas que ejecutan un pequeño subconjunto de tu base de código. Los componentes que acceden a la base de datos se pueden burlar / troquelar para todo lo que dependa de ellos.
Una cosa que hice fue crear métodos estáticos que devolvieran 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!