Supongo que llamaré, ya que realmente no me gustan algunas de las respuestas hasta ahora.
Ya sea que lo llame una "prueba de unidad" o "prueba de integración" o una "prueba supercalifragilisticexpialidocious" no importa un poco en este caso; solo hay una prueba válida para los componentes de acceso a datos y que es para probarla en datos reales. No producción datos obviamente, pero un facsímil razonable de eso.
Lo primero que debe hacer es get the database itself under source control. Lamentablemente, no hay un marco para esto; Microsoft parte del camino en algunas versiones de VSTS, pero el resultado final aún es algo que falta. Al menos en el mundo de hoy, vas a tener que hacer mucho de este trabajo tú mismo. Pero hazlo, en serio: no te arrepentirás cuando se estropee una actualización importante y necesites deshacer la base de datos.
Lo que se pone bajo control de origen debería ser todo lo necesario para generar el nuevo esquema, por lo general una secuencia de comandos de línea de base, además de las secuencias de comandos de configuración "datos" (es decir, el contenido de tablas de enumeración), y actualizar las secuencias de comandos para reflejar los cambios de esquema recientes. Esto le da casi todo lo que necesita para realizar pruebas "en vivo" en una base de datos temporal; su prueba solo necesita descargar esos scripts desde el control fuente y ejecutarlos en un servidor de prueba y/o una instancia de base de datos diferente, usualmente usando SQL Management Objects para ejecutar dichos scripts (SMO puede manejar declaraciones GO y similares; un SqlConnection normal no puede).
Varias herramientas pueden ayudarlo con la generación de contenido de prueba en la base de datos de prueba. Probablemente el más popular es el SQL Data Generator de Red Gate. Estas herramientas también pueden generar scripts para crear los datos, que es lo que usará en sus pruebas. O bien, si así lo desea, puede eliminar los datos de su base de datos de producción y usar SQL Server Management Studio para crear una secuencia de comandos con los datos que elija conservar para la prueba. De cualquier forma, mantenga sus scripts de datos de prueba en control de fuente, al igual que los scripts de esquema, y cuando necesite probar su DAL, descargue estos scripts luego de activar una instancia de DB y utilizarlos para completar los datos.
Me gustaría que eran un único marco que hacer todo esto para usted, pero con el derecho de cobro de herramientas, bibliotecas y buenas prácticas de desarrollo, que puede convertir esto en un proceso mucho menos doloroso.
Estoy de acuerdo con esto por completo. – kyoryu
He usado SQL Server Express de Microsoft para plataformas de prueba; verificamos los archivos .mdf en el control de fuente. (SQL Server recreará archivos .ldf sobre la marcha). Esto no es divertido, y terminas aprendiendo mucho más sobre la RANU y las instancias de usuario de lo que siempre quisieras saber. Pero funciona. – TrueWill
@TrueWill: Hard core, espero que esas bases de datos de prueba sean pequeñas, de lo contrario, ¡eso masticará mucho espacio en el disco en el servidor SC! Definitivamente es una opción para considerar si se ajusta a su infraestructura; para nosotros, incluso si redujéramos nuestra base de datos de 1.5 TB a 1.5 GB para probarla, sería un poco ridículo verificar la fuente. ;) – Aaronaught