¿Alguien ha tenido éxito en la prueba unitaria de los procedimientos almacenados de SQL?

Hemos encontrado que las pruebas de unidad que hemos escrito para nuestro código C # / C ++ realmente han valido la pena. Pero aún tenemos miles de líneas de lógica de negocios en procedimientos almacenados, que solo se ponen a prueba con ira cuando nuestro producto se extiende a una gran cantidad de usuarios.

Lo que empeora esto es que algunos de estos procedimientos almacenados terminan siendo muy largos, debido al impacto en el rendimiento al pasar tablas temporales entre los SP. Esto nos ha impedido refactorizar para simplificar el código.

Hemos hecho varios intentos de crear pruebas de unidad en torno a algunos de nuestros procedimientos almacenados clave (principalmente la prueba de rendimiento), pero hemos encontrado que configurar los datos de prueba para estas pruebas es realmente difícil. Por ejemplo, terminamos copiando alrededor de las bases de datos de prueba. Además de esto, las pruebas terminan siendo realmente sensibles al cambio, e incluso el cambio más pequeño en un proceso almacenado. o tabla requiere una gran cantidad de cambios a las pruebas. Por lo tanto, después de que muchas compilaciones se rompen debido a que estas pruebas de base de datos fallan de manera intermitente, solo hemos tenido que sacarlas del proceso de compilación.

Entonces, la parte principal de mis preguntas es: ¿alguna vez alguien ha escrito con éxito pruebas de unidad para sus procedimientos almacenados?

La segunda parte de mis preguntas es si la prueba de unidad sería / es más fácil con linq?

Estaba pensando que en lugar de tener que configurar tablas de datos de prueba, ¿podría simplemente crear una colección de objetos de prueba y probar su código de linq en una situación de "linq a objetos"? (Soy totalmente nuevo en linq, así que no sé si esto funcionaría)

Respuestas a la pregunta(16)

Su respuesta a la pregunta