Playwright y MCP: cómo un agente de IA prueba UI y base de datos sin assertions SQL manuales

Un toast verde después de hacer clic en el botón "Finalizar compra" no significa que el pedido se haya creado realmente. Si la transacción se revirtió, la cola perdió un mensaje y la UI seguía mostrando "éxito", la prueba end-to-end da una falsa sensación de confiabilidad. Es por eso que cada vez más equipos están mirando hacia la verificación full-stack, donde no solo se verifica la interfaz, sino también el estado real de los datos en la base de datos.

En el enfoque clásico, esa verificación requiere que la infraestructura de pruebas tenga acceso direto a la BD a través de un ORM o controlador de bajo nivel. Luego comienzan los gastos generales: credenciales separadas, configuración de conexión, aserciones SQL manuales, mantenimiento de consultas con cada cambio de esquema. Formalmente esto resuelve el problema, pero el costo crece con el número de escenarios.

Cada nueva prueba end-to-end se convierte no solo en una verificación del comportamiento del usuario, sino en un mini-proyecto de mantenimiento de código de prueba. El artículo cubre un patrón más ligero: un agente AI trabaja secuencialmente con dos servidores MCP a la vez. Primero, a través de Playwright ejecuta un escenario en el navegador como un usuario normal—llena el carrito, pasa por el checkout, hace clic en el botón de confirmación y captura indicadores clave del resultado.

Luego el mismo agente cambia a un servidor que puede leer la estructura de la base de datos y responder consultas de verificación sin que el tester escriba SQL manualmente. Esencialmente, el agente solo necesita formular exactamente qué necesita ser confirmado: ¿existe el registro del pedido, coinciden los artículos, se dedujo el saldo del producto, cambió el estado del pago. Este enfoque cierra la brecha principal entre "la UI mostró éxito" y "la operación comercial realmente se completó."

El agente puede hacer coincidir datos de la interfaz con registros en tablas, verificar efectos secundarios e incluso tener en cuenta la asincronía si el sistema no escribe en la BD instantáneamente. Para equipos de producto esto es especialmente importante en escenarios donde un botón del usuario dispara una cadena de acciones: creación de pedido, reserva de inventario, escritura en sistema de logística, actualización de estado del cliente. Es en estos lugares donde surgen con más frecuencia bugs costosos, aquellos que las pruebas normales de UI no detectan.

El valor práctico de este patrón es que reduce la barrera para pruebas full-stack. Los equipos no necesitan arrastrar un ORM a las pruebas solo para algunas verificaciones y duplicar el conocimiento del esquema de la base en código de aserciones. En su lugar, hay una única capa de verificación a nivel de intención: "después del checkout debe aparecer un registro de pedido," "el número de artículos debe coincidir," "el saldo del almacén debe disminuir en una unidad."

Si el esquema cambia, el mantenimiento se mueve más cerca del servidor MCP o de la descripción del acceso a datos, en lugar de dispersarse en docenas de pruebas. Como resultado, las pruebas se vuelven más cortas, más comprensibles y más cercanas al lenguaje empresarial. Al mismo tiempo, este escenario no anula la disciplina básica de ingeniería.

No puedes confiar solo en el agente AI: las pruebas unitarias y de integración siguen siendo necesarias para localizar rápidamente errores a nivel de función, servicio y contrato. El acceso a la base para el agente debe ser restringido, preferiblemente de solo lectura y solo en un entorno de prueba. También se necesitan medidas de previsibilidad: datos de prueba estables, reglas de selección claras, protección contra que el agente verifique accidentalmente el pedido incorrecto en una base compartida.

De lo contrario, una herramienta conveniente rápidamente se convierte en una fuente de fallos ruidosos y difíciles de reproducir. La conclusión principal aquí es simple: el siguiente paso en la evolución de las pruebas end-to-end es la transición de verificar pantallas a verificar las consecuencias reales de la acción del usuario. La combinación de Playwright y MCP hace que esta transición sea significativamente más barata porque elimina SQL manual del trabajo diario del tester y permite que una automación recorra el camino desde el clic del botón hasta el hecho de un registro de base de datos.

Para equipos que prueban pagos, pedidos, reservas y otras transacciones críticas, esto no es solo una técnica conveniente sino una forma de reducir el número de pruebas falsos positivos y detectar bugs más temprano que antes se filtraban a producción.