TestTrout

El asistente de pruebas para aplicaciones construidas con IA.

Ejecútalo como una aplicación, o entrégaselo a tu agente de codificación a través de MCP. De cualquier manera, escribe las pruebas que tu aplicación nunca tuvo y te dice cuándo fallan.

Las truchas son una especie indicadora. Solo viven en aguas limpias y bien oxigenadas: si encuentras una en un arroyo, sabes que el agua está sana sin necesidad de analizarla.

Eso es lo que es un buen conjunto de pruebas: no una tarea pesada, sino una señal que puedes leer de un vistazo.

El problema

Los agentes de codificación entregan rápido. También rompen cosas silenciosamente, y las aplicaciones que construyen — Lovable, v0, Bolt, React hecho a mano en Vercel — casi nunca tienen pruebas. Así que el ciclo termina con un "me parece bien" de la misma cosa que acaba de escribir el código.

TestTrout cierra ese ciclo. Lee el repositorio, se conecta al despliegue en ejecución, averigua qué no está probado y en qué orden importa, escribe pruebas reales, las ejecuta y reporta resultados sobre los que realmente puedes actuar.

Related MCP server: Lastest

Ponlo en marcha

pip install testtrout
trout up

Almacenamiento, un trabajador y la interfaz en localhost:7411. Sin Docker, sin demonio, sin base de datos que instalar — SQLite en ~/.testtrout, trabajador en proceso. Sin API key de ningún tipo. Nada aquí llama a un modelo.

Cómo funciona

Añade un proyecto — una carpeta en esta máquina y la URL donde está desplegado.

trout add ~/code/my-app --url https://my-app.vercel.app

Luego cuatro pasos, que también son cuatro comandos:

trout look     # read the code, ask the deployment, work out what is testable
trout facts    # what I still need from you — all optional
trout build    # write the baseline and prove it
trout run      # re-run it and report what changed

Una línea base es lo que tu despliegue hace hoy. TestTrout la registra y asegura que siga ocurriendo. No sabe si el comportamiento actual es correcto — nadie se lo ha dicho — y nunca lo preguntará. Sabe cuál es el comportamiento, y nota el día que cambia.

Esa única regla es la razón por la que no hay entrevista, ni cola de aprobación, ni lista de preguntas sobre tu producto. Lo único que pide son valores concretos que no puede descubrir:

Cada una se responde en segundos, cada una es opcional, y cada una dice qué desbloquea. Dale una URL y nada más, y obtienes cada página que carga sin sesión iniciada — que en la mayoría de las aplicaciones ya es un conjunto útil.

Todo lo que averigua se guarda como un artefacto en la barra lateral — el mapa del proyecto, el formulario, el plan de pruebas, la suite de línea base — para que nada importante quede tres pantallas arriba en un historial de chat.

O quédate en tu agente de codificación

La aplicación es una forma de entrar, no la única. Todo lo que hace está disponible como herramientas MCP tipadas y como comandos CLI, para que cualquiera que prefiera no salir de su editor no tenga que hacerlo:

pip install 'testtrout[mcp]'
trout mcp /path/to/your/project

Apunta a tu agente a la habilidad en .claude/skills/, o dile:

Usa el servidor MCP de TestTrout. Mira el repositorio, dime qué necesita todavía de mí, luego construye la línea base y ejecútala.

Siete herramientas, vinculadas a un proyecto para que un agente no pueda actuar sobre el repositorio equivocado:

Además, trout://map, trout://facts, trout://plan, trout://config, trout://scenarios como recursos, para que el estado masivo nunca abarrote la ventana de contexto de un agente.

Lo que entiende

trout look lee código sin acceso a la red en absoluto, por lo que es seguro en un repositorio que acabas de clonar. En una aplicación típica de Supabase encuentra:

También te dice cuándo una tabla se escribe desde código de navegador sin seguridad a nivel de fila — lo que significa que es escribible por cualquiera a través de la clave anónima. Eso suele ser una novedad.

Nunca pide tu base de datos

Las pruebas llegan a tu aplicación como lo hace un usuario: HTTP contra tus endpoints, y un navegador real contra tu interfaz. El inicio de sesión pasa por tu propio formulario de login, que trout look localiza una vez para que las pruebas reproduzcan un formulario conocido en lugar de adivinar.

Así que todo necesita una URL y dos cuentas de prueba. Sin clave anónima, sin rol de servicio, sin credenciales de proyecto — nada que la mayoría de los equipos se negaría razonablemente a entregar a una herramienta de pruebas.

La autorización sigue cubierta, y posiblemente mejor: con sesión iniciada como dos cuentas ordinarias, lo que una pueda ver, la otra no debe. Eso ejercita tus políticas y todo lo que tu aplicación añade sobre ellas, que es lo que encuentra un usuario real.

Por qué las pruebas son dignas de confianza

Construye una línea base, no conjeturas por PR. Una prueba derivada del código que acabas de cambiar afirma que el nuevo comportamiento es correcto por construcción — no puede detectar una regresión. TestTrout certifica una suite contra un despliegue funcionando primero, así que un fallo significa algo.

Sin modelo, en ninguna parte. Ni en el escaneo, ni en la planificación, ni al escribir una prueba. Cada afirmación se remonta a algo que el despliegue realmente hizo, por eso las mismas entradas siempre producen la misma suite y por eso no hay API key que configurar.

Cada afirmación lleva su procedencia, y en una línea base siempre es observed — con la evidencia escrita en el archivo generado:

// observed: the page title when /orders was loaded
await expect(page).toHaveTitle('Orders');
// observed: seen on /orders at baseline
await expect(page.getByTestId('orders-table')).toBeVisible();

Solo envía un GET. Las pruebas de endpoints reproducen la solicitud que hizo la sonda, cualesquiera que sean los métodos que el endpoint declare, así que apuntar esto a producción no puede cambiar nada allí.

Un fallo se clasifica antes de reportarse. Solo assertion_failure es una señal de producto. Los fallos de autenticación, las bases de datos inalcanzables y las llamadas a terceros bloqueadas son del arnés, y una ejecución inconclusa nunca se actualiza a un pase.

Todo desde la terminal

trout add ~/code/my-app --url https://my-app.vercel.app
trout look          # read the code, ask the deployment
trout facts         # what I still need — all optional
trout build         # write the baseline and prove it
trout run           # re-run it; a failure means behaviour changed

Cada comando soporta --json. Guía completa en docs/setup.md.

Cómo almacena las cosas

Tu suite de pruebas permanece en tu repositorio, confirmada y revisable:

.trout/scenarios/*.yaml    what each test asserts, in plain language
.trout/facts.yaml          what was asked for — never a secret value
.trout/plan.yaml           what can be tested, and what is waiting
.trout/config.yaml         deployments and env: references, never secrets
tests/trout/               generated Playwright and Vitest files

El historial de ejecuciones, la cobertura a lo largo del tiempo y la cola de trabajos viven en SQLite en ~/.testtrout. Esa división es deliberada: la suite pertenece junto al código donde una solicitud de extracción puede revisarla, y las preguntas que los archivos no pueden responder — ¿esta prueba se está volviendo más inestable, está subiendo la cobertura? — pertenecen a una base de datos.

Vista web opcional

trout web

Cobertura de un vistazo, la lista clasificada de brechas, revisión de escenarios, historial de ejecuciones con evidencia, registro en vivo. Los mismos archivos .trout/ que la CLI — sin base de datos, nada alojado, solo loopback. Totalmente opcional; la CLI y MCP son completos por sí solos.

Seguridad

La herramienta necesita tus credenciales de base de datos y puede manejar tu despliegue, así que las garantías se aplican en el código en lugar de documentarse:

• La producción es de solo lectura por defecto. Las solicitudes de mutación están bloqueadas en la capa de red a menos que un punto de entrada esté explícitamente marcado como disposable. La protección está por debajo de la navegación, porque "solo cargar una página es de solo lectura" es falso — muchas de estas aplicaciones escriben al montar. Ningún agente, y ningún clic web, puede cambiar esa configuración.

• Los terceros son interceptados. Una ejecución de pruebas no puede cobrar una tarjeta ni enviar un correo a un cliente. Las solicitudes salientes no coincidentes fallan ruidosamente; un mock que silenciosamente no coincide con nada es como una suite reporta verde mientras no prueba nada.

• Los secretos no entran en archivos confirmados. .trout/config.yaml contiene solo referencias env:. Los valores viven en un .env ignorado por git.

• Nada está alojado, y nada sale de tu máquina. No hay modelo al que llamar ni cuenta que crear. Sin telemetría.

Stacks compatibles

React + Vite (Lovable, v0, Bolt) y Next.js App Router, en TypeScript, con Supabase, desplegado en cualquier lugar accesible por HTTP. Autenticación mediante Supabase, Clerk o NextAuth.

Deliberadamente limitado. La profundidad en un stack supera a la cobertura superficial de muchos — y estos codebases son lo suficientemente regulares como para que el análisis estático sea genuinamente preciso en ellos. Otros stacks están a un adaptador de distancia: ver docs/adapters.md.

Hoja de ruta

Contribuir

Añadir un framework, proveedor de autenticación o ejecutor de pruebas significa implementar un protocolo y registrar un punto de entrada — sin necesidad de fork. Ver CONTRIBUTING.md y docs/adapters.md.

La suite de pruebas completa se ejecuta sin conexión y sin API key. Eso es deliberado y vale la pena mantenerlo.

Licencia

Apache 2.0