pruebas unitarias TSQL

Question

¿Hay alguien ahí fuera escribir pruebas unitarias para sus procedimientos de TSQL almacenados, triggers, funciones, etc ...

recientemente he comenzado a hacer base de datos y restauraciones e instala parte de nuestro crucero automático acumulación de Control proceso. Ahora estoy pensando en llevarlo al siguiente nivel donde hacemos la instalación, luego ejecutar una lista de pruebas de procedimientos almacenados, etc.

Iba a hacer solo mi propio uso de Extensiones MsBuild para invocar las pruebas. Sin embargo, estoy al tanto de http://www.tsqltest.org/ y http://tsqlunit.sourceforge.net/. También sé que TFS tiene pruebas sql.

Solo quería ver lo que las personas en el mundo real están haciendo y si tienen alguna sugerencia.

Gracias

Answer 1

que han utilizado la prueba de la base de datos que está integrado en Visual Studio 2008 Database Edition en un proyecto aquí. Funciona bien, pero se siente más como un tercero conectado a Visual Studio que como un componente nativo. Algunos de los dolores que sentía con él son:

• Debido a que el código SQL vive en los archivos de res y un único archivo de código puede incluir varias pruebas, que no es tan fácil la búsqueda de pruebas basadas en los nombres de tablas/columnas.
• Debido a que las pruebas múltiples viven en los mismos archivos de código, tiene algunas colisiones de nombres de variables molestas (por ejemplo, si tiene dos pruebas en un solo archivo de código, todas las afirmaciones de esas pruebas deben tener nombres únicos; los nombres de las afirmaciones probablemente se verán como "testname_assertionname", que realmente no debería ser necesario).
• La refacturación de sus pruebas no es fácil; por ejemplo, si desea trasladar una prueba de un archivo de código a otro, la forma más fácil es crear la prueba desde cero en el nuevo archivo porque hay partes de la prueba dispersos sobre el archivo res y el archivo de código.

Todo eso dicho, como comencé - Funciona bien. Desafortunadamente, aún no hemos agregado estas pruebas a nuestro servidor de integración continua, por lo que no puedo comentar lo fácil que es automatizar la ejecución de estas pruebas. Estamos utilizando TFS para CI, y estoy asumiendo que la automatización de las pruebas funcionaría de forma muy similar a la automatización de las pruebas de unidades estándar; En otras palabras, parece que debería haber una línea de comando MSTest que ejecutara las pruebas.

Por supuesto, esta es solo una opción si tiene licencia para ejecutar Visual Studio 2008 DB Edition (que entiendo ahora está incluido en la licencia VS 2008 Pro).

Answer 2

Procedimientos almacenados. Generalmente, incluyo consultas de prueba en comentarios en el encabezado SP, y registro resultados correctos y tiempos de consulta. Esto todavía lo deja como un ejercicio manual, sin embargo).

Funciones. Nuevamente, coloque declaraciones SQL en el encabezado con la misma información.

Disparadores. Los evito por varias razones, una de ellas es que son tan difíciles de probar y depurar por tan poco beneficio en comparación con poner la misma lógica en otro nivel. Es como preguntar cómo probar la Integridad Referencial.

Esto sigue siendo un proceso manual, sin embargo. Pero dado que creo que uno debería intencionalmente diseñar artefactos SQL para ser desacoplados por completo (por ejemplo, ningún SP que llame a SP, lo mismo con funciones y otro ataque contra desencadenantes en mi humilde opinión) es relativamente menos complejo.

Answer 3

Las partes críticas:

• Que sea automatizado y integrado con su construcción/prueba (por lo que tiene un verde o rojo de su construcción)
• Que sea fácil de añadir una nueva prueba
• Mantenga sus pruebas hasta a la fecha de

avanzada:

• condiciones de fallo de prueba en su código
• asegúrese de que sus pruebas de limpiar después de sí mismos (ejemplo guiones de TSqlTest utilizan @beforeCount y las variables @afterCount para validar la limpieza)

Answer 4

He hecho esto en Java, usando dbunit.

Básicamente, cualquier cosa que haga en la base de datos ya sea: devuelve un conjunto de resultados o altera el estado de la base de datos.

El estado de la base de datos se puede describir como todos los valores en todas las filas en toda la tabla en todos los esquemas de una base de datos; el estado de cualquier subconjunto es el estado de todos los datos afectados por alguna prueba.

Por lo tanto, comience con una base de datos llena de datos de prueba suficientes para que pueda realizar las pruebas, llame a esto la línea de base. Extraiga una instantánea, con dbunit o la herramienta de su elección.

Dado que su base de datos se encuentra en la línea de base, cualquier conjunto de resultados es determinista (siempre que su sp sea determinista, menos si es "select random();").

Obtenga el conjunto de resultados de referencia de todos sus SP, guárdelos como instantáneas con dbunit o la herramienta que esté utilizando.

Para probar las operaciones que no cambian de estado, simplemente pruebe que el conjunto de resultados que obtiene es el que recibió inicialmente. Para probar operaciones que cambian la base de datos, pruebe esa línea base + operación = cambio esperado. Después de cada prueba que potencialmente reduce el DB, restáurelo a la línea base.

Básicamente, la capacidad de restaurar a una línea base hace que las pruebas sean posibles.

Answer 5

¿Has probado a usar la API de red-gate.com?

Tienen un montón de productos para comparar cosas en SQL Server y la API permite virtualmente la misma funcionalidad mediante programación.

http://help.red-gate.com/help/SQLDataCompareAPIv5/4/en/GettingStartedAPI.html