Régis Baccaro

Pruebas de unidad con SQL Server Data Tools

December 24, 2016 by

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.

Getting the latest version of SSDT
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.

Automatically checking for new versions
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).

Creating unit tests from Projects node
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.

Choosing which element to create test for
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:

Configuring the test project
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ó:

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!

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.

Writing the unit test
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).

Successful test run
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.

Removing test from build process
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

Régis Baccaro

Régis Baccaro

Régis es un Consultor Principal en Rehfeld que trabaja con bases de datos y administraciones desde 1999. Él ha estado trabajando con Inteligencia de Negocios desde SQL Server 2000 y con SharePoint desde 2003. Él se especializa en tutoría, ajustes de desempeño y arquitectura escalable de almacenes de datos y soluciones de BI.

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
Régis Baccaro
Desarrollo de base de datos SQL

Acerca de Régis Baccaro

Régis es un Consultor Principal en Rehfeld que trabaja con bases de datos y administraciones desde 1999. Él ha estado trabajando con Inteligencia de Negocios desde SQL Server 2000 y con SharePoint desde 2003. Él se especializa en tutoría, ajustes de desempeño y arquitectura escalable de almacenes de datos y soluciones de BI. Sus antecedentes y experiencia de trabajo mezclan tecnología y negocios, proveyéndole una ventaja única para contribuir a proyectos de almacenes de datos y 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 comunitario SQL 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

168 Views