Testing de bases de datos: cómo validar consultas, tablas y procedimientos

Hay que probar la base de datos además de la aplicación porque probar únicamente a través de la interfaz de usuario deja un punto ciego importante: solo se comprueba lo que la interfaz muestra, no lo que realmente ocurre con los datos por debajo. Muchos errores de la capa de datos son silenciosos, en el sentido de que no producen ningún síntoma visible en la pantalla en el momento en que se cometen, pero corrompen o degradan los datos de forma que tarde o temprano causa problemas. Por ejemplo, una consulta puede calcular mal un total pero devolverlo con el formato correcto, de modo que en pantalla se ve un número plausible aunque esté equivocado; una unión entre tablas mal planteada puede duplicar filas sin que se note si la interfaz solo muestra un resumen; una restricción que falta puede permitir que entre un dato inválido o inconsistente que nadie advierte hasta que otra parte del sistema tropieza con él; o un procedimiento almacenado puede actualizar más registros de los debidos. Todos estos son fallos que una prueba centrada en la interfaz difícilmente detecta, porque la interfaz miente por omisión: enseña una versión parcial y presentable de un estado que puede estar dañado. Dado que los datos son casi siempre el activo más valioso e irreemplazable de un sistema, ya que el código y la infraestructura se pueden reconstruir pero los datos de los usuarios no, un error en la capa de datos es de los más costosos que existen. Por eso el testing de base de datos mira directamente los datos, las consultas, el esquema y la lógica que vive en la propia base, en lugar de conformarse con su reflejo en la pantalla, y constituye una capa de protección esencial para la integridad de la información.

Al probar consultas, lo que se valida es que devuelvan exactamente los datos correctos en todas las situaciones relevantes, y no solo en el caso más sencillo. Esto abarca varios aspectos. En primer lugar, se comprueba que los cálculos y las agregaciones que realiza la consulta, como sumas, promedios, conteos y agrupaciones, produzcan el resultado matemáticamente correcto, ya que un error sutil en un cálculo puede pasar inadvertido en pantalla pero falsear informes y decisiones. En segundo lugar, se verifica que las uniones entre tablas se comporten como corresponde, sin duplicar filas por una relación de uno a muchos mal manejada ni perder filas que deberían aparecer, algo especialmente delicado porque las uniones son una fuente clásica de resultados engañosos. En tercer lugar, se valida que los filtros seleccionen justo el conjunto de registros que deben, ni de más ni de menos, comprobando las condiciones con distintos valores. En cuarto lugar, y muy importante, se prueban los casos límite y especiales, como conjuntos de datos vacíos, valores en los extremos de los rangos, y el manejo de los valores nulos que representan la ausencia de dato, ya que estos casos son donde más frecuentemente fallan las consultas y donde el comportamiento por defecto puede sorprender. Para probar todo esto de forma fiable, se parte de un conjunto de datos de prueba conocido y controlado, de manera que se sepa de antemano cuál debe ser el resultado exacto de cada consulta y se pueda comparar con lo que realmente devuelve. En conjunto, probar consultas consiste en tratar cada consulta como una función que, ante unas entradas conocidas, debe producir una salida exacta, y verificar rigurosamente que así sea tanto en los casos normales como en los límite.

Las restricciones del esquema, como las claves primarias y foráneas, las restricciones de unicidad, las de no nulo y otras reglas de validación, se prueban de una manera que resulta un poco contraintuitiva al principio: en lugar de comprobar que la base acepta los datos correctos, se comprueba sobre todo que rechaza los datos incorrectos. La idea es que el valor de una restricción está precisamente en impedir que entren datos inválidos o inconsistentes, de modo que la prueba consiste en intentar deliberadamente introducir esos datos malos y verificar que la base de datos los rechaza como debe. Por ejemplo, para probar una restricción de unicidad, se intenta insertar dos registros con el mismo valor en la columna que debe ser única y se verifica que el segundo es rechazado; para probar una restricción de no nulo, se intenta insertar un registro dejando vacío ese campo y se comprueba que la operación falla; para probar una clave foránea, se intenta crear un registro que apunte a otro inexistente y se verifica que la base lo impide; y para probar una regla de validación, se intenta guardar un valor fuera del rango o formato permitido y se confirma que no se acepta. Este enfoque es importante porque el mero hecho de que una restricción esté definida en el esquema no garantiza que funcione como se espera en todos los casos, ni que no haya sido debilitada o mal configurada, y tampoco garantiza que la aplicación no tenga alguna vía por la que se salten esas comprobaciones. Probar las restricciones intentando violarlas confirma que la última línea de defensa de la integridad de los datos, que reside en la propia base de datos, está efectivamente activa y hace su trabajo, lo cual es especialmente valioso porque esa defensa protege los datos incluso frente a errores de la aplicación o accesos por vías inesperadas.

No se debe probar contra la base de datos de producción por dos razones fundamentales, una de riesgo y otra de fiabilidad. La razón de riesgo es que las pruebas suelen crear, modificar y borrar datos, y hacerlo sobre la base real, la que usan los usuarios y contiene su información, puede corromper o destruir datos valiosos, generar registros falsos, disparar procesos reales indeseados como envíos de correos o cobros, y en general provocar daños difíciles o imposibles de revertir. A esto se suma una cuestión de privacidad y cumplimiento normativo muy seria: los datos de producción suelen contener información personal y sensible de personas reales, y usarlos para pruebas los expone innecesariamente y puede vulnerar la normativa de protección de datos, por lo que incluso copiarlos a un entorno de pruebas requiere, como mínimo, anonimizarlos o enmascararlos adecuadamente. La razón de fiabilidad es que la base de producción es un blanco móvil e impredecible: sus datos cambian constantemente por la actividad de los usuarios, de modo que una prueba que hoy espera encontrar cierto número de registros o cierto valor puede fallar mañana no porque haya un bug, sino porque los datos cambiaron, generando resultados erráticos y falsos positivos o negativos que erosionan la confianza en las pruebas. El testing fiable requiere partir de un estado conocido y reproducible, con datos de prueba controlados que uno mismo prepara y cuyos resultados esperados conoce de antemano. Por todo ello, la práctica correcta es usar un entorno de pruebas dedicado, con una base de datos poblada con datos de prueba diseñados para los casos que se quieren cubrir, aislada de la de producción, y dejar la base de producción exclusivamente para el uso real, protegida de cualquier operación de prueba.

Dejar la base de datos limpia entre pruebas, es decir, asegurarse de que cada prueba parte del mismo estado conocido y no se ve afectada por lo que hicieron las pruebas anteriores, es una de las claves para tener un testing de datos fiable y no frágil, y existen varias técnicas para lograrlo. La más elegante y recomendada, cuando es aplicable, consiste en envolver cada prueba en una transacción y, al terminar la prueba, en lugar de confirmar los cambios, revertirlos con una operación de deshacer. De este modo, todo lo que la prueba insertó, modificó o borró se anula al final, y la base de datos vuelve automáticamente al estado exacto en que estaba antes de la prueba, sin que los cambios lleguen siquiera a hacerse permanentes; esta técnica es rápida y muy limpia, ya que no requiere borrar nada manualmente. Una segunda técnica es recrear el estado inicial antes de cada prueba, ya sea vaciando y volviendo a poblar las tablas con el conjunto de datos de prueba conocido, o incluso recreando la base de datos desde cero a partir de un esquema y unos datos semilla; es más lenta pero garantiza un punto de partida idéntico y sirve incluso cuando la prueba necesita que los cambios se confirmen. Una tercera opción es que cada prueba limpie explícitamente lo que creó al terminar, aunque esta es la más propensa a errores, porque es fácil olvidar borrar algo o hacerlo en el orden equivocado por las dependencias entre tablas. El principio de fondo, cualquiera que sea la técnica, es que ninguna prueba debe depender del estado que dejó otra ni del orden en que se ejecutan las pruebas, porque esa dependencia produce el peor tipo de fragilidad, en la que las pruebas pasan o fallan según qué otras corrieron antes. Garantizar el aislamiento y la limpieza entre pruebas es lo que hace que los resultados sean reproducibles y dignos de confianza.

El testing de bases de datos se puede automatizar mediante dos grandes enfoques, a menudo complementarios, cada uno con sus herramientas características. El primer enfoque consiste en escribir las pruebas dentro de la propia base de datos, usando marcos de pruebas específicos para cada motor que permiten expresar las verificaciones en el lenguaje de la base, es decir, en SQL o en su lenguaje de procedimientos. Estos marcos son especialmente útiles para probar objetos que viven dentro de la base, como los procedimientos almacenados, las funciones, los disparadores y las restricciones, porque las pruebas se ejecutan en el mismo entorno que el código que verifican y pueden comprobar directamente el comportamiento de esos objetos, incluyendo a menudo mecanismos para preparar datos y revertir los cambios al final de cada prueba. El segundo enfoque consiste en probar la base de datos desde el código de la aplicación, escribiendo pruebas en el mismo lenguaje de programación del proyecto que se conectan a una base de datos de prueba, preparan un estado conocido, ejecutan las operaciones o consultas que se quieren verificar, y comprueban que el resultado y el estado de los datos son los esperados; estas pruebas encajan de forma natural como pruebas de integración, ya que verifican la interacción real entre el código y la base de datos. Ambos enfoques se integran en los procesos de automatización continua, de modo que las pruebas de base de datos se ejecutan automáticamente ante cada cambio, junto con el resto de la suite, alertando enseguida si una modificación rompe una consulta, una restricción o un procedimiento. La elección entre uno y otro, o su combinación, depende de qué se quiera probar y de las prácticas del equipo, pero en cualquier caso lo importante es que las pruebas de datos partan de un estado controlado, dejen la base limpia y se ejecuten de forma repetible, para que su automatización aporte confianza real y no falsos resultados.