Introducción
En diciembre de 2012, una gran adición fue hecha a SSDT: La habilidad de hacer pruebas de unidad de bases de datos.
De todas maneras, esta característica no está disponible en la edición gratis de SSDT. Para hacer pruebas de unidad con SSDT usted necesitará al menos Visual Studio Professional o superior.
A medida que usted y los miembros del equipo hacen cambios al esquema de la base de datos, usted puede verificar que estos cambios están funcionando como se espera o si ellos han roto funcionalidad existente.
Por favor soporte mis muchas capturas de pantalla, pero fui lo bastante afortunado para obtener una licencia de SnagIt® de TechSmith, así que también estoy probando las posibilidades de esta herramienta en este artículo. 🙂
Procediendo
Usualmente usted querrá establecer la línea base de su base de datos y luego correr algunas pruebas de unidad en los cambios que usted ha hecho. Personalmente, he hecho un hábito de tomar instantáneas de la base de datos en la que estoy trabajando en diferentes etapas al menos una vez a la semana. De esta manera, siempre puedo volver al estado anterior a cuando hice los cambios subsecuentes sin tener que retrotraer los cambios con TFS.
Ya que las pruebas de unidad de su base de datos son sólo un “Proyecto de Pruebas de Unidad”, usted puede crear y correr pruebas de unidad de bases de datos sin un proyecto de base de datos. De todos modos, la única manera de autogenerar pruebas para objetos específicos de la base de datos es usar el proyecto de base de datos.
Cuando esté creando un proyecto de pruebas desde un proyecto de base de datos, Visual Studio generará automáticamente algunas clases para usted. La mayor parte del trabajo será hecho de esa manera. La clase más importante en ese aspecto es:
Microsoft.Data.Tools.Schema.Sql.UnitTesting;
Verificando la última versión de SSDT
Primero usted necesita verificar si tiene la última versión de SSDT. Esto es hecho con el menú Check for Updates debajo del menú SQL.
Figura 1: Obteniendo la última versión de SSDT
Cuando esté verificando las actualizaciones, usted también tiene la posibilidad de dejar que Visual Studio lo haga por usted automáticamente seleccionando automatically check for updates to SQL Server Data Tools.
Figura 2: Verificando automáticamente nuevas versiones
Usando Proyectos en SQL Server Object Explorer (SSOX)
Cada vez que usted presiona F5, SSDT desplegará su base de datos a su LocalDB. Por cierto, es posible cambiar este comportamiento yendo a la pestaña Debug de la página de propiedades del proyecto y cambiando la cadena de conexión ahí, de modo que su base de datos sea desplegada en algún otro lugar que en esta instancia local.
Creando una Prueba de Unidad de SQL Server desde un objeto existente en la base de datos
Desde SDT usted puede crear automáticamente stubs para hacer pruebas de unidad a procedimientos almacenados, funciones y desencadenadores.
Digamos que queremos probar un procedimiento almacenado llamado uspRankCustomer que creamos en un artículo anterior. Vea Continuous integration with SQL Server Data Tools and Team Foundation Server para obtener un script para crear la base de datos. Alternativamente, use este script incrustado con el esquema completo de la base de datos usado en este ejemplo.
Encuentre el procedimiento almacenado para el que desea crear el stub de prueba y haga clic derecho en él en el nodo del proyecto de SSOX (tenga en cuenta que el nodo Projects no contendrá su proyecto de base de datos antes de que haya desplegado/publicado exitosamente su base de datos).
Figura 3: Creando pruebas de unidad desde el nodo Projects
En la ventana que se muestra después usted puede elegir si desea crear un proyecto de pruebas VB.Net o C# así como una lista de todos los objetos de la base de datos que soportan pruebas de unidad y el nombre de la clase para el archivo de prueba siendo creado.
Figura 4: Eligiendo qué elemento para el que crear pruebas
Yo elijo C# y después de la creación del proyecto, usted es presentado con el diálogo SQL Server Test Configuration, donde usted puede especificar qué base de datos correr la prueba, incluso una conexión secundaria para validar esas pruebas, así como la opción para desplegar la base de datos previamente a correr sus pruebas.
Observación: Si usted debe probar vistas o procedimientos almacenados que tienen permisos restringidos, usted típicamente especificaría esa conexión en este paso. Usted luego especificaría la conexión secundaria con más permisos para validar la prueba. Si usted tiene una conexión secundaria, usted debería añadir ese usuario al proyecto de base de datos y crear un inicio de sesión para ese usuario en el script de pre despliegue.
En mi caso, deseo correr mis pruebas en la base de datos que desplegué antes. Así es como se ve mi configuración:
Figura 5: Configurando el proyecto de pruebas
Si usted ve el explorador de soluciones, usted verá que lo siguiente fue creado:
- Un proyecto de pruebas
- Un SqlDatabaseSetupFile
- Una clase SQLUnitTest
- El archivo app.config del proyecto contiene los ajustes para el despliegue y la conexión con la base de datos
Definir la lógica de pruebas
Mi base de datos es bastante simple y contiene 3 tablas y 3 procedimientos almacenados. En mi entrada anterior, creé una tabla y un procedimiento para categorizar clientes. Ahora quiero probar si mi procedimiento de categorización uspRankCustomers funciona como se espera y categoriza los clientes como se especifica en la tabla de ranking.
Aquí está el simple procedimiento almacenado que se usó:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
CREATE PROCEDURE [dbo].[uspRankCustomers] AS DECLARE @CustomerId int DECLARE @OrderTotal money DECLARE @RankingId int DECLARE curCustomer CURSOR FOR SELECT c.CustomerID, ISNULL(SUM(oh.OrderTotal), 0) AS OrderTotal FROM dbo.Customer AS c LEFT OUTER JOIN dbo.OrderHeader AS oh ON c.CustomerID = oh.CustomerID Group BY c.CustomerId OPEN curCustomer FETCH NEXT FROM curCustomer INTO @CustomerId, @OrderTotal WHILE @@FETCH_STATUS = 0 BEGIN IF @OrderTotal = 0 SET @RankingId = 1 ELSE IF @OrderTotal < 100 SET @RankingId = 2 ELSE IF @OrderTotal < 1000 SET @RankingId = 3 ELSE IF @OrderTotal < 10000 SET @RankingId = 4 ELSE SET @RankingId = 5 UPDATE Customer SET RankingId = @RankingId WHERE CustomerId = @CustomerId FETCH NEXT FROM curCustomer INTO @CustomerId, @OrderTotal END CLOSE curCustomer DEALLOCATE curCustomer |
Prueba: Para mis clientes existentes, quiero actualizar el ranking usando la tabla Ranking.
Paso 1: Definir el script de prueba
Deseo ejecutar mi procedimiento almacenado y asegurarme de que no hay nulls en rankingID de la tabla de clientes. ¡De esta manera, puedo estar seguro de que todos los clientes han sido categorizados!
|
1 2 3 4 5 6 7 8 9 10 11 12 |
-- database unit test for dbo.uspRankCustomers DECLARE @RC AS INT; SELECT @RC = 0; -- execute the stored procedure EXECUTE @RC = [dbo].[uspRankCustomers] ; -- select the customer ids without any ranking (should be 0) SELECT @RC = CustomerID from Customer where RankingID IS NULL SELECT @RC AS RC; |
En Test conditions, elimine la condición automáticamente creada y cree una nueva. Cambie su tipo a Scalar Value y en la ventana de propiedades asegúrese que Expected value es 0.
Figura 6: Escribiendo la prueba de unidad
Paso 2: Corriendo la prueba
En la pestaña Test haga clic en Windows y luego Test Explorer. La ventana Test Explorer debería aparecer, listando su prueba. Haga clic derecho en ella y elija Run Selected Test. Ahora debería correr y mostrar un ícono verde si es un éxito (o uno rojo en el evento de un fallo).
Figura 7: Ejecución de prueba exitosa
Si usted recuerda la entrada previa en esta serie, hice posible hacer despliegues contínuos con MSBuild y Team Foundation Server. Mostré cómo usted puede generar y desplegar los cambios en su base de datos para cada registro. Bueno, también es posible hacer que este procedimiento corra la prueba por usted. Esto es útil para correr pruebas automatizadas y analizar el impacto de cambios de código en sus pruebas como parte de su proceso de generación.
Pero por ahora lo deshabilitaremos en el archivo Build Definition. En el panel izquierdo elija Process y haga clic en la elipsis en el lado derecho de Automated Test y haga clic en Remove en el diálogo que se muestra.
Figura 8: Removiendo la prueba del proceso de generación
Correr una prueba como parte de su Proceso de Generación será el tema de las entradas siguientes, ¡así que permanezca atento para más SSDT y diversión de pruebas de unidad!
Lea más acerca de pruebas de unidad en Visual Studio: Verifying Database Code by Using SQL Server Unit Tests
Sus antecedentes y experiencia de trabajo mezclan tecnología y negocios, proveyéndole una ventaja única para contribuir a proyectos de almacenes de datosy SharePoint, pudiendo interactuar efectivamente con tomadores de decisiones técnicos y de negocios.
Régis es un expositor frecuente en conferencias de SQL Server y es un miembro de Danish SQL Server User Group y el fundador del evento comunitarioSQL Saturday Denmark.
En abril de 2014 Régis recibió el galardón de MVP para SQL Server por su involucramiento en el producto y la comunidad.
View all posts by Régis Baccaro
- Pruebas de unidad con SQL Server Data Tools - December 24, 2016
- Integración Continua con SQL Server Data Tools y Team Foundation Server - December 4, 2015