¿BDD en SQL Server?
TL;DR Judo Github repo: https://github.com/redbeestudios/judo
Uno de los desafíos que tuvimos este año con mi equipo fue resolver varios problemas que tenía el proceso de conciliación de movimientos (transacciones) de nuestro proyecto.
A simple vista, la conciliación consiste en encontrar dos registros que representan el mismo movimiento dentro de dos conjuntos de información.
Todo el sistema de conciliación estaba implementado sobre Microsoft SQL Server. Y consistía en aproximadamente 30 (largos) procedures de SQL que se ejecutaban en secuencia para, de manera muy resumida, obtener los conjuntos de datos, compararlos, y conciliar los iguales.
Por varias razones, que no aplican a este post, migrar el sistema a otro lenguaje estaba fuera de la mesa.
Cuando hizo click
Después de haber trabajado unas semanas sobre los stored procedures del proceso me encontré realizando repetitivamente la misma tarea: probando a mano (y a ojo) que los resultados de un procedure sean los esperados.
Encontré que la forma más organizada era utilizando bloques de código SQL de la siguiente manera:
Después de cubrir varias historias de esta manera, el siguiente paso era obvio. ¿Cómo lograr que estas pruebas no mueran conmigo y que la validación no tuviese que ser a ojo? (todavía no morí y ya perdí esas pruebas :v )
- ¡Necesitamos crear un framework que nos permita replicar esto!
Pero Joaco, me dirán, ¿por qué no usaste herramientas ya existentes como DbUnit, o tSQLt, etc?
Para responder esa pregunta es necesario entender la necesidad que se quería satisfacer, y eso lo podemos resumir en estos puntos:
- Negocio: La idea no era simplemente generar tests unitarios (DbUnit) sobre los procedures, sino poder cubrir los requerimientos del negocio, idealmente generando una documentación al mismo tiempo.
- Tenemos que migrar esto: SQL Server es código legacy, usar una herramienta en ese lenguaje (tSQLt) significaba atarnos más a esa implementación, lo que hubiera dificultado una migración en el futuro.
- Equipo de QA y POs: Era necesario pensar que si el framework llegase a cierta madurez podría ser usado por no programadores. Por lo que era necesario encontrar un DSL adecuado.
- Sencillez: Al estar probando la base de datos, la generación de datos (llenar las tablas) era uno de los puntos más importantes. Por lo tanto era un requerimiento que la misma se pueda realizar lo más sencillamente posible.
Open Source & Cucumber al rescate
Cucumber es una herramienta muy útil para realizar BDD que, más allá de las funcionalidades básicas: especificaciones en texto plano, validaciones, etc (que pueden leer en el link, ya que no voy a entrar en detalle sobre cómo funciona), tenía algo que resultó crucial para nuestro framework: ¡Data Tables!
Solo quedaba darle forma…
Judo: Framework de BDD para SQL
Sin meterme mucho en lo técnico, ya que eso va a quedar como material para otro posteo.
El primer paso fue llegar al MVP (minimum viable product) para entender si la idea valía la pena. El mismo consistía en lo siguiente:
- Insertar datos en una tabla
- Ejecutar un store procedure
- Validar los datos en una tabla
Para lograr esto aprovechamos la funcionalidad de cucumber de parsear los archivos Gherkin, lo que nos permitió definir steps de la siguiente manera (siguiendo el ejemplo de más arriba):
Insertar datos en una tabla
Ejecutar un stored procedure
Validar los datos en una tabla
¡Y funcionó, ejecutando Judo podíamos probar la funcionalidad!
De ahí en adelante fue sólo cuestión de cubrir el proceso de conciliación con Judo e ir agregando funcionalidades a medida que las necesitaba. Y así Judo pasó de MVP a beta con funcionalidades como:
- La base de datos no se ve afectada: Cada escenario corre dentro de una transacción, la cual es rollbackeada al finalizar.
- Manipulación del contexto del test: Es posible guardar tanto variables como los resultados de los inserts en tablas para reutilizar más adelante en la prueba.
- Generar pruebas sobre funciones de SQL
- Distintos tipos de validación para tablas y variables
- Internacionalización: Actualmente se pueden escribir las especificaciones tanto en Inglés como en Español.
Conclusión: volviendo a la conciliación
¡Tenemos cobertura en SQL! (barrita púrpura).
Judo nos permitió cubrir las necesidades más importantes para el negocio del proceso de conciliación y principalmente dejar de pushear código cruzando los dedos (en el mejor escenario, con pruebas manuales).
Tener tests redujo drásticamente la vuelta de errores, como también poder hacer TDDD (Test & Data Driven Development) aceleró la velocidad del equipo para resolver estas tareas.
Para finalizar, dejo un ejemplo (levemente alterado) de Judo en un caso productivo como es el de conciliación.
Si hice las cosas bien no debería tener que explicar nada :3
Judo es un proyecto Open Source y lo podés encontrar en nuestro github redbeestudios/judo. ¡Los PRs son más que bienvenidos!
