Respuesta.

Historia de la pregunta
La verificación manual de la lógica empresarial en SQL (a nivel de procedimientos almacenados, funciones, desencadenadores) conduce a errores que solo aparecen en producción. Durante mucho tiempo, la prueba de scripts SQL fue informal y no estandarizada. Sin embargo, el desarrollo de tecnologías CI/CD requiere pruebas automatizadas también para el código SQL.

Problema
La mayoría de los desarrolladores se limita a las pruebas a nivel de aplicación. La falta de verificación de los propios procedimientos y funciones SQL conduce a defectos que no están cubiertos por ningún paquete de pruebas, por ejemplo, al cambiar la lógica de UDF o regresiones en los informes.

Solución
En los flujos de trabajo de los equipos modernos, se organizan pruebas unitarias e integradas directamente para el código SQL. Para la prueba unitaria se utilizan frameworks como tSQLt (SQL Server), utPLSQL (Oracle), pgTAP (PostgreSQL), y para la prueba integrada, entornos separados para levantar bases temporales, aplicar migraciones y verificar escenarios de negocio.

Ejemplo de prueba unitaria en pgTAP:

-- Comprobamos la separación por salario
SELECT plan(2);
SELECT is( (SELECT calc_salary(1)), 1000, 'El salario para el usuario 1 es correcto' );
SELECT isnt( (SELECT calc_salary(2)), 0, 'El salario del usuario 2 no es cero' );
SELECT finish();

Código de prueba integrada para CI/CD:

psql -U user -d testdb < migrations.sql
psql -U user -d testdb < test_data.sql
psql -U user -d testdb -c "SELECT * FROM my_procedure_test();"

Características clave:

• Las pruebas deben estar aisladas, tener un conjunto de datos independiente (setup/teardown).
• Ejecución automática de pruebas en la pipeline de CI/CD.
• Verificación no solo de la corrección de los datos, sino también de errores/situaciones límite/condiciones de salida.

Preguntas trampa.

¿Se pueden hacer solo pruebas automáticas a nivel de aplicación si los procedimientos son grandes? No, porque las pruebas de UI/API no garantizan la correcta operación de la lógica SQL (por ejemplo, condiciones incorrectas dentro de funciones almacenadas o violaciones al actualizar datos). Las pruebas unitarias deben cubrir todas las ramas raíz de ejecuciones en el propio código SQL.

¿Son suficientes las ejecuciones "manuales" de scripts de prueba — dado que hay pocos cambios en la base? No son suficientes, incluso en proyectos pequeños aparecen errores tras cambios en el esquema o la lógica. La automatización de pruebas en el proceso CI reduce el factor humano y evita regresiones.

¿Se pueden probar solo los procedimientos "críticos", dejando el resto? El mejor enfoque es cubrir la mayor cantidad posible de funciones, especialmente si en el futuro varias equipos van a cambiar el código: cálculos no evidentes y casos límite suelen aparecer en ramas no estándar.

Errores típicos y anti-patrones

• Falta de setup/teardown → las pruebas influyen entre sí
• Cobertura solo de escenarios "positivos", ausencia de pruebas negativas
• Estructura de datos de prueba compleja/no mantenible

Ejemplo de la vida real

Caso negativo

Al modificar el procedimiento de cálculo de descuentos, se probaron manualmente un par de casos, pero se pasaron por alto las principales ramas de la lógica. En producción, los clientes comenzaron a recibir descuentos incorrectos, y se tardó varios días en resolverlo.

Ventajas:
Ahorro de tiempo al principio.

Desventajas:
Pérdidas en correcciones manuales, incomodidad en modificaciones y refactorización.

Caso positivo

Se desarrollaron pruebas unitarias con pgTAP para todas las UDF y procedimientos clave, las pruebas integradas se ejecutan a través de CI en cada fusión de ramas. Errores y regresiones se detectan antes del despliegue.

Ventajas:
Estabilidad de las funciones, posibilidad de mejorar rápidamente la lógica empresarial, mínimos errores en producción.

Desventajas:
Se requiere inversión de tiempo para iniciar y mantener la base de pruebas.