Las pruebas de extremo a extremo cambian los resultados
Un agente puede poner todos los tests unitarios en verde y aun así entregar algo roto, porque el bug se esconde en las costuras entre las piezas. Solo una corrida de extremo a extremo toca esas costuras.
Un motor que pasa en el banco puede calarse en el tráfico, porque los fallos viven en el cableado entre las piezas. Los tests unitarios prueban las piezas en el banco; una corrida de extremo a extremo es la prueba en carretera. Agentum añade una segunda puerta que ejercita el producto como lo haría un usuario.
Los bugs viven en las costuras
Los tests unitarios confirman cada componente en aislamiento; la autorrevisión confirma el modelo mental del propio agente. Ninguno toca las fronteras de integración, el cableado, la config, el I/O real, donde ocurren la mayoría de los fallos en producción. Una suite unitaria en verde junto a un producto roto es un estado muy común y muy engañoso.
flowchart LR Unit["verify.sh, puerta unitaria"] -->|verde| RT["ready_to_test"] RT --> QA["QA de navegador, Chrome via MCP"] QA -->|veredicto pass| Done["done"] QA -->|no concluyente| Fail["la puerta falla"] linkStyle 0 stroke:#2ea043,stroke-width:2.5px,color:#2ea043 linkStyle 2 stroke:#2ea043,stroke-width:2.5px,color:#2ea043 linkStyle 3 stroke:#e0493f,stroke-width:2.5px,color:#e0493f
Qué cambia una puerta de extremo a extremo
Cuando la puerta de verificación corre todo el pipeline como lo haría un usuario, cambian dos cosas. Primero, atrapas los fallos de integración que los tests unitarios estructuralmente no pueden. Segundo, y más sutil, el agente empieza a construir para la realidad de extremo a extremo, porque es lo que se califica. La forma de la puerta moldea el trabajo; una puerta de pipeline completo produce software que de verdad corre.
La puerta de dos fases
Agentum integra el principio de extremo a extremo en una puerta de dos fases. Primero corre verify.sh como puerta unitaria. Cuando pasa, la función pasa a ready_to_test y corre una segunda puerta a nivel de navegador: según qa_mode, o un script qa.sh o un verdadero agente de bucle de verificación por navegador que maneja Chrome por el MCP de Playwright/CDP y escribe un veredicto en .agentum-harness/qa/<id>.json. Un veredicto no concluyente falla la puerta. Solo cuando ambas fases están en verde la función llega a done, el producto se comprueba como un usuario lo ejercitaría de verdad.
Puntos clave
- Los tests unitarios y la autorrevisión pasan por alto fallos de integración, las costuras entre unidades.
- Una puerta de extremo a extremo atrapa lo que los tests unitarios estructuralmente no pueden.
- La forma de la puerta moldea el trabajo: califica todo el pipeline y el agente construirá para él.
- Agentum corre contra un entorno real, así que la verificación puede ser una corrida de extremo a extremo genuina.
Ejercicios
- Encuentra la costura. Nombra un bug que todos tus tests unitarios pasarían por alto. ¿Qué chequeo de extremo a extremo lo atraparía?
- Escribe un e2e. Programa el camino de usuario más importante de principio a fin.