2012-02-23 9 views
5

He estado escribiendo algunas pruebas de unidad de base de datos tSQLt (a través de Red Gate SQL Test) en procedimientos que llaman a tablas que contienen columnas (persistentes) recientemente, y tenga en cuenta que si utilizo FakeTable SP, Encuentro que las columnas calculadas no están pobladas (se evalúan como nulas). La columna calculada es clave para la prueba, por lo que no puedo ignorar la columna en la prueba, y prefiero no duplicar la lógica.Pruebas unitarias con tSQLt en columnas calculadas

Estoy evaluando los resultados usando el tSQLt.AssertEqualsTable SP, por lo que quiero asegurarme de que los valores de columna sean los mismos en ambos.

En la práctica, he solucionado esto al no usar FakeTable, sino al usar una declaración de transacción de retrotracción (parcial) al final de la prueba (por publicación de blog en http://sqlity.net/en/585/how-to-rollback-in-procedures/) o eliminar explícitamente los valores de prueba.

Estoy seguro de que debe haber una forma mejor de codificar esta prueba y agradecería cualquier sugerencia.

Respuesta

4

Debe separar la lógica en la columna calculada de la lógica en el procedimiento al realizar la prueba. El procedimiento tomará la información en esa columna y actuará en consecuencia. El procedimiento no debería importar que la columna sea una columna calculada o una columna real. Eso significa que en su prueba puede codificar un valor para poner en esa columna. FakeTable lo hace posible convirtiendo cualquier columna calculada en una columna real.

En otro conjunto de pruebas, puede (y debe) probar que la columna calculada se calcule correctamente. Para eso está disponible una adición a FakeTable. Esto conserva la propiedad calculada de la tabla. Debe establecer el parámetro @ComputedColumn de EXECUTE tSQLt.FakeTable en 1. (http://tsqlt.org/user-guide/isolating-dependencies/faketable/)

Por cierto, no necesita deshacer nada en una prueba. tSQLt se está ocupando de eso ya. La lógica descrita en el artículo que mencionó solo es necesaria en su propio procedimiento, si la gestión de transacciones es un requisito de ese proceso.

+0

Gracias Sabastian, eso es muy útil. Intenté combinar las dos pruebas, pero como usted señala, estas deberían ser pruebas diferentes. – DaveGreen

3

Ahora hay una actualización de la versión preliminar a tSQLt disponible en la lista de correo: http://groups.google.com/group/tsqlt

El pre-lanzamiento contiene características para preservar columnas o valores predeterminados calculados durante FakeTable.

Ejemplos:
EXEC tSQLt.FakeTable 'dbo.tst1', @ComputedColumns = 1;
EXEC tSQLt.FakeTable 'dbo.tst1', @Defaults = 1;

Pronto estarán listos para su lanzamiento oficial.