Este es un tema que genera quilombo en cualquier conversación de QA.
Te lo digo porque ya lo viví: estás en una revisión de código y alguien pregunta “¿por qué tu test consulta la base de datos?” y se arma.
De un lado, los que dicen que un test automatizado jamás debería tocar la base. Del otro, los que no entienden cómo validás que algo se guardó bien sin verificar el dato real.
Y la respuesta honesta es: depende.
Pero no “depende” como respuesta evasiva. Depende de verdad, con criterios concretos.
Cuándo sí aporta valor
Hay escenarios donde validar contra la base no solo tiene sentido, sino que es lo único que te da confianza real.
Y acá va una anécdota que me pasó más de una vez (no voy a decir dónde): el servicio me devolvía una cosa y en la base había otra. Datos que no matcheaban, campos con valores distintos, respuestas que parecían correctas pero que atrás estaban mal persistidas. Cosas que una vez reportadas se tuvieron que arreglar sí o sí.
Además, “chusmear” la base te ayuda a encontrar inconsistencias que de otra forma no verías: nombres de campos raros, tipos de datos que no tienen sentido, estructuras que no coinciden con lo que esperarías. Ese tipo de hallazgos muchas veces terminan en reportes que mejoran la calidad del sistema más allá del test puntual.
1. Cuando el front no expone todo lo que se guarda
A veces el sistema te muestra “Operación exitosa” pero atrás falló la mitad de los inserts. Si tu test solo valida el mensaje en pantalla, te estás perdiendo el problema real.
2. Cuando hay lógica de negocio en la persistencia
Triggers, stored procedures, campos calculados, auditoría. Si el comportamiento crítico pasa por ahí, tu test necesita llegar a verificar que efectivamente ocurrió.
3. Cuando los datos son sensibles o regulados
Sistemas financieros, salud, legales. No alcanza con “el front dijo que se guardó”. Necesitás confirmar que el registro existe, tiene el estado correcto y cumple las reglas de integridad.
4. Cuando estás integrando sistemas
El clásico caso de “le pegamos a un servicio externo y guardamos la respuesta”. Ahí querés asegurarte de que lo que llegó se persistió como corresponde.
Cuándo rompe aislamiento y suma ruido
También hay casos donde validar contra la base se convierte en un problema más que en una solución.
1. Cuando el test se acopla al schema
Si cada cambio de columna te rompe 40 tests, algo está mal. Tu suite de automatización no debería ser un contrato rígido con la estructura de la base.
2. Cuando validás cosas que ya validó otra capa
Si tu API tiene tests de integración que verifican persistencia, ¿necesitás que el test E2E también lo haga? Probablemente no. Repetir validaciones en varias capas no suma confianza, suma mantenimiento.
3. Cuando el entorno no lo permite
Bases compartidas, datos de otros equipos mezclados, fixtures frágiles. Conectarte a la base en ese contexto es más riesgo que beneficio.
4. Cuando el test se vuelve lento por las queries
Si tu suite pasa de correr en 2 minutos a tardar 20 porque cada caso hace 5 consultas, empezás a perder la gracia del feedback rápido.
Cómo lo resuelvo en la práctica
Lo que a mí me funciona es separar responsabilidades.
- Tests E2E: validan flujos de usuario desde el front. No tocan la base salvo excepciones muy justificadas.
- Tests de integración: validan contratos de API y, cuando corresponde, verifican persistencia real.
- Tests de componente o unitarios: no tocan base nunca. Mockean todo.
Y cuando necesito validar contra la base, uso una estrategia simple:
- El test prepara su propio contexto (inserta datos limpios o usa un identificador único).
- Ejecuta la acción.
- Consulta la base para verificar el resultado.
- Limpia lo que creó.
Así el test no depende de que alguien más haya dejado datos previos ni ensucia el entorno para los que vengan después.
¿Es más laburo? Sí. Pero es laburo que escala.
Lo que me quedó claro
Validar contra la base de datos no es ni buena práctica absoluta ni sobreingeniería automática.
Es una herramienta más. Y como toda herramienta, el valor está en usarla cuando resuelve un problema real, no por costumbre o porque “siempre se hizo así”.
Si tu test necesita esa validación para tener sentido, dale. Si la estás agregando “por las dudas” o porque te parece más completo, probablemente estés sumando acoplamiento sin ganar confianza.
La pregunta que me hago antes de agregar una consulta a la base en un test es simple:
¿Este dato lo puedo verificar de otra forma más aislada? ¿O la única forma de saber si funcionó es ir a buscarlo?
Si la respuesta es la segunda, adelante. Si es la primera, capaz conviene dar un paso atrás y pensar si no estás complicando algo que podría ser más simple.