TesterArmy e2e
Arquitectura de TesterArmy e2e: observar, actuar, afirmar, grabar
Seguir cómo se unen un paso semántico y una aserción normal
Qué aprenderás
- Separar componentes
- Seguir decisiones
- Situar la repetición
Antes de empezar
- Una app o cuenta de prueba descartable
- Un motor web o móvil
- Una elección deliberada de modelo para pasos de agente
Dos ejecuciones y una modificación deliberada prueban el límite de la caché
Conclusiones clave
- Runner y motor tienen funciones distintas.
- Agente y localizador verifican cosas diferentes.
- Repetir necesita estado final válido.
Separar componentes
El runner selecciona objetivo y motor, abre la app y ejecuta fixtures. El motor proporciona observaciones y acciones; el ejecutor del agente decide el siguiente movimiento durante un paso adaptable.
`agent.act` y `agent.assert` no son aserciones de localizador. Los primeros pueden pedir acciones o juicios al modelo; una aserción explícita comprueba un elemento especificado por la API.
Seguir decisiones
Los archivos fijados `act.ts` y executor muestran observaciones, elección de herramientas, acciones y comprobaciones de finalización. El paquete decision-model ofrece otra ruta acotada con puertas propias.
Que un modelo declare terminado el objetivo no basta para cualquier prueba. Combine el paso adaptable con una aserción estable si existe un elemento DOM o de accesibilidad nativa fiable.
Situar la repetición
El grabador conserva acciones reproducibles cuando hay un estado final verificable. `replay.ts` intenta aplicarlas bajo los límites del paso y mira la pantalla actual.
Si el objetivo se mueve o falla el estado final, la repetición se detiene. El diseño evita tratar coordenadas antiguas como prueba de éxito nuevo, aunque la fiabilidad solo puede confirmarse ejecutando.
Cómo elegir
| Criterio | Opción A | Opción B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Pasos de implementación
- 1
Identificar objetivo, motor y fixture.
- 2
Seguir observación, acción y aserción por separado.
- 3
Inspeccionar por qué se acepta o rechaza una traza.
Ejemplo para copiar
runner -> target engine -> observation
observation -> agent action -> app
app -> assertion -> trace recorder
next run -> conditional replay -> end-state checkPreguntas frecuentes
¿Siempre decide el modelo el resultado?
No. Puede haber aserciones explícitas y el primer ejemplo no usa modelo.
¿Solo pulsa coordenadas guardadas?
El código fijado incluye reubicación, límites y verificación del estado final.
Fuentes
- TesterArmy e2e / docs/quickstart.mdxFuente verificada 2026-10-14
- TesterArmy e2e / docs/reference/runner.mdxFuente verificada 2026-10-14
- TesterArmy e2e / docs/reference/engine.mdxFuente verificada 2026-10-14
- TesterArmy e2e / packages/e2e/src/agent/act.tsFuente verificada 2026-10-14
- TesterArmy e2e / packages/e2e/src/agent/executor.tsFuente verificada 2026-10-14
- TesterArmy e2e / packages/e2e/src/agent/replay.tsFuente verificada 2026-10-14
- TesterArmy e2e / packages/e2e/src/cache/recorder.tsFuente verificada 2026-10-14
- TesterArmy e2e / packages/e2e/src/run/runner.tsFuente verificada 2026-10-14