La integración con bases de datos es una de las formas más comunes de pruebas de integración. Muchos sistemas dependen de guardar, consultar, actualizar y eliminar información correctamente.
Una prueba unitaria puede verificar una regla de negocio en memoria, pero no confirma que una consulta funcione contra el esquema real, que una entidad se guarde con sus relaciones o que una migración haya dejado la base en el estado esperado.
En este tema veremos cómo probar integraciones con bases de datos de manera clara, segura y repetible.
Una prueba de integración con base de datos puede verificar varias cosas:
Para este tipo de integración, conviene usar una base de datos real de prueba, separada de producción. Esto permite detectar problemas que no aparecerían si todo se simula.
Una base real de prueba permite verificar:
La base debe ser de prueba. Nunca debería apuntarse accidentalmente a una base productiva.
El esquema de la base de datos define tablas, columnas, restricciones, índices y relaciones. Si el esquema no coincide con lo que espera el código, la integración fallará.
Las migraciones ayudan a versionar cambios en el esquema. En pruebas de integración, es importante verificar que la base se prepare con las migraciones correctas.
Errores típicos:
Muchas aplicaciones encapsulan el acceso a datos en repositorios, DAOs o capas similares. Estas piezas son candidatas naturales para pruebas de integración porque dependen de una base real.
Una prueba puede verificar que un repositorio:
Estas pruebas son útiles porque muchas fallas ocurren en la traducción entre objetos del código y registros de base de datos.
Una integración con base de datos suele involucrar relaciones. Por ejemplo, una orden puede tener un cliente, varios ítems y pagos asociados.
La prueba debe verificar que:
Probar solo la entidad principal puede ocultar errores en relaciones y datos secundarios.
Las consultas son una fuente frecuente de errores de integración. Un filtro puede estar invertido, una condición puede faltar o un join puede excluir registros válidos.
Conviene probar consultas importantes con datos preparados específicamente para revelar errores.
Por ejemplo, para probar una consulta de pedidos pendientes, deberíamos preparar:
No alcanza con cargar un solo registro que coincide. También necesitamos datos que no deben coincidir para comprobar que el filtro excluye correctamente.
Las restricciones ayudan a proteger la consistencia de los datos. En integración, es importante saber cómo responde la aplicación cuando una restricción se cumple o se viola.
Ejemplos de restricciones:
La prueba puede verificar que la aplicación no intente guardar datos inválidos o que maneje correctamente el error de la base cuando ocurre.
Las pruebas con base de datos necesitan datos iniciales bien definidos. Estos datos pueden cargarse con scripts, fixtures, fábricas o pasos de preparación dentro de la prueba.
Los datos iniciales deben ser:
Los datos de prueba deben expresar el caso que se está verificando. Si son demasiado grandes o genéricos, la prueba pierde claridad.
Las pruebas de integración con base de datos deben limpiar los datos creados o restaurar un estado conocido. Si no, aparecen duplicados, interferencias y fallas dependientes del orden.
Estrategias posibles:
La estrategia debe equilibrar seguridad, velocidad y simplicidad.
Las transacciones permiten agrupar operaciones para que se confirmen o se reviertan como una unidad. En pruebas de integración, son importantes por dos motivos: ayudan a probar consistencia y pueden ayudar a limpiar.
Una prueba puede verificar que:
El tema siguiente profundizará en transacciones, persistencia y consistencia de datos.
Algunas pruebas usan bases de datos en memoria porque son rápidas y fáciles de crear. Pueden ser útiles, pero tienen limitaciones.
| Opción | Ventaja | Riesgo |
|---|---|---|
| Base en memoria | Rápida y simple para pruebas pequeñas. | Puede comportarse distinto a la base real. |
| Base real de prueba | Detecta diferencias reales de tipos, consultas y restricciones. | Requiere más preparación y limpieza. |
Si producción usa un motor específico, conviene que las pruebas importantes usen el mismo motor o uno muy compatible.
Las pruebas de integración no reemplazan a las pruebas de rendimiento, pero pueden revelar problemas obvios en consultas. Por ejemplo, una consulta que hace muchas lecturas innecesarias o que falla con un conjunto de datos moderado.
En este nivel, conviene prestar atención a:
No se trata de medir capacidad máxima, sino de detectar problemas técnicos evidentes antes de avanzar.
Supongamos que queremos probar la integración del servicio de órdenes con la base de datos.
| Paso | Qué verifica |
|---|---|
| Preparar cliente y producto. | Datos iniciales suficientes para crear la orden. |
| Ejecutar creación de orden. | El servicio colabora con el repositorio. |
| Consultar la orden guardada. | La persistencia se realizó correctamente. |
| Verificar ítems y total. | Las relaciones y cálculos quedaron registrados. |
| Limpiar datos creados. | La prueba no deja residuos para otras pruebas. |
Al probar integración con bases de datos, suelen aparecer errores como:
Antes de confiar en una prueba de integración con base de datos, conviene revisar:
Las bases de datos son una fuente central de integración en muchas aplicaciones. Probar contra una base de prueba bien preparada permite detectar errores de persistencia, consultas, relaciones, restricciones y configuración.
Una buena prueba de integración con base de datos no solo ejecuta una operación. También prepara datos, verifica el estado final y limpia lo que creó.
En el próximo tema profundizaremos en transacciones, persistencia y consistencia de datos.