rf-test-agents · Agentes de IA universales para pruebas con Robot Framework
rf-test-agents es un conjunto de código abierto (Apache 2.0, versión 1.0.0) de cinco agentes de IA para Robot Framework que planifican, generan, reparan, verifican y documentan las pruebas, contrastando el plan y cada paso generado con la aplicación viva mediante el servidor MCP rf-mcp (RobotMCP). El ciclo completo plan → generate → heal → verify → istqb funciona en Claude Code y GitHub Copilot; es independiente de la tecnología y se apoya en controles mecánicos y bucles de retroalimentación cerrados.
El puente que faltaba entre los LLM y la ejecución real
Los asistentes de código generalistas generan pruebas estáticas que fallan desde su primera ejecución. rf-test-agents lleva la potencia de los agentes de prueba autónomos al ecosistema Robot Framework apoyándose en el servidor estándar rf-mcp para pilotar la aplicación viva paso a paso.
Universal y multicanal
Funciona con cualquier biblioteca que rf-mcp pueda cargar: Browser / Playwright o Selenium para la web, RequestsLibrary para las API HTTP/REST, AppiumLibrary para el móvil y DatabaseLibrary.
Controles mecánicos
El plan en specs/ es la fuente de verdad. Las modificaciones quedan selladas con un hash SHA256 (check_spec_sync.py). Los selectores en bruto y los Sleep se rechazan mecánicamente (check_conventions.py).
Multihost: Claude y Copilot
Disponible en Claude Code mediante comandos slash con un hook de permisos PreToolUse, y en GitHub Copilot en VS Code mediante chat modes generados a partir de las mismas definiciones de agentes; la CI comprueba que siguen sincronizados (regen_agent_definitions.py --check).
El ciclo cerrado plan → generate → heal → verify → istqb
Un bucle de retroalimentación hermético en el que cada rol dispone de prerrogativas estrictas para garantizar que el plan siga siendo honesto y que las pruebas sigan siendo un instrumento de medición fiable. Es la aplicación del Spec-Test-Driven Development (STDD): la especificación, escrita en lenguaje humano y confrontada con el sistema vivo, guía la prueba, y la prueba guía el desarrollo. Para verlo en acción con un caso SAP real: el vídeo STDD (8 min 34).
Frente a TDD. STDD conserva la lógica de TDD y la adelanta un ladrillo. TDD es rojo, verde, refactor: primero el test, que falla, y luego el código que lo hace pasar. En STDD el primer ladrillo es la spec, y una spec es verde por defecto, en teoría: se escribe, se cree y nadie la ejecuta, así que nada puede hacerla fallar. STDD la somete a la prueba del sistema real: roja donde el sistema la refuta, verde una vez observada, y solo entonces llegan el test y el código.
Cinco agentes especializados con fronteras estancas
Cada agente dispone de un perímetro de acción estrictamente delimitado. Los roles nunca se mezclan: quien escribe no es quien verifica, y quien repara no tiene derecho a rebajar el nivel de exigencia.
rf-verifier
Revisión independiente e imparcial de las modificaciones de prueba. Inspecciona el invariante de negocio inicial, los diffs de código y las pruebas de ejecución. Sin herramientas de escritura, sin comandos de shell y sin delegación, no puede ser influido.
rf-planner
Explora la aplicación viva mediante rf-mcp (snapshots del árbol de accesibilidad ARIA y respuestas reales de API). Formaliza el recorrido en specs/ en puro lenguaje de negocio, donde cada hecho consignado se ha constatado en vivo, nunca se ha adivinado.
rf-generator
Convierte una especificación en una suite estándar de Robot Framework. Su regla fundacional: ningún paso entra en el archivo .robot sin haberse ejecutado con éxito en vivo sobre la aplicación. Crea los page objects en resources/.
rf-healer
Repara las suites en rojo ajustando la capa de automatización (resources/page_objects/). Tiene formalmente prohibido tocar las aserciones o las pruebas. Presupuestos de procedimiento estrictos (2 candidatos, 20 llamadas, 900 s) y 5 veredictos estructurados.
rf-istqb
Diseñador documental sin conexión (sin sesión rf-mcp activa). Traduce los planes y registros en fichas de prueba normalizadas ISO 29119-3 / ISTQB con bloques YAML de reproducción neutros, directamente utilizables por personas o por otras IA.
Controles mecánicos, no promesas verbales
La confianza en los agentes de IA no se basa en su supuesta buena voluntad, sino en scripts de control automatizados y en barreras de sincronización infranqueables.
Procedencia SHA256 (check_spec_sync.py)
Cada suite generada sella la huella criptográfica de su plan de origen. Si se modifica un archivo de specs/ sin volver a ejecutar el generador, la CI falla en cada push y el hook de edición de Claude Code señala la desviación.
Control de convenciones (check_conventions.py)
Rechaza mecánicamente cualquier selector en bruto (CSS, XPath, ID) en el cuerpo de las pruebas y prohíbe todo Sleep arbitrario. Solo se admiten las sincronizaciones de estado explícitas.
Memoria de deriva (heal-journal.md)
Cada reparación realizada por rf-healer registra un informe de incidente: causa identificada, diff antes/después y prueba de reproducción en verde. El planner consulta este diario antes de cualquier nueva pasada de exploración.
Primeros pasos con Claude Code y VS Code
Instale el núcleo de código abierto en unos segundos y pilote sus primeros escenarios con sus agentes de IA habituales.
# Clonar el repositorio de código abierto
git clone https://github.com/CyrilM29/rf-test-agents.git
cd rf-test-agents
# Crear el entorno virtual e instalar las dependencias
python -m venv .venv
source .venv/bin/activate # En Windows: .venv\Scripts\activate
pip install -r requirements.txt
# Inicializar Playwright para el canal Browser (opcional)
rfbrowser init# Abrir el proyecto en Claude Code
claude
# 1. Planificar en vivo sobre la aplicación viva
/rf-plan el recorrido de inicio de sesión en https://miapp.example.com
# 2. Generar la suite de Robot Framework ejecutada paso a paso
/rf-generate specs/recorrido-inicio-sesion.md
# 3. Reparar automáticamente en caso de deriva de la interfaz
/rf-heal tests/robot/ui/web/recorrido_inicio_sesion.robot
# 4. Auditar en solo lectura el invariante y las pruebas
/rf-verify# Con GitHub Copilot en VS Code:
# 1. Abrir la carpeta rf-test-agents en VS Code
# 2. .vscode/mcp.json declara automáticamente el servidor rf-mcp
# 3. Abrir el chat de Copilot y seleccionar el modo de agente deseado:
# - @rf-planner: explorar la aplicación y redactar la especificación
# - @rf-generator: generar la suite con verificación en vivo
# - @rf-healer: reparar los localizadores sin debilitar la prueba
# - @rf-istqb: generar la documentación de prueba ISO 29119-3Comprender la arquitectura de rf-test-agents
Las decisiones de ingeniería fundamentales que garantizan la independencia tecnológica, la ausencia de alucinaciones y la integridad absoluta de sus pruebas.
¿Por qué rf-test-agents es universal e independiente de la tecnología?
A diferencia de las extensiones propietarias cerradas a una sola herramienta, rf-test-agents aprovecha las primitivas universales del servidor RobotMCP (rf-mcp). Pilota indistintamente aplicaciones web (Browser/Playwright, SeleniumLibrary), API HTTP (RequestsLibrary), aplicaciones móviles (AppiumLibrary) o bases de datos relacionales, sin ningún plugin cautivo.
- Primitivas estandarizadas: árbol de accesibilidad ARIA, acciones nativas y ejecución
execute_stepunificada. - Independencia total: interoperabilidad directa con todo el ecosistema oficial de Robot Framework.
¿Por qué rf-generator exige ejecutar en vivo cada paso antes de la generación?
Los modelos de lenguaje alucinan con frecuencia selectores inexistentes o esperas arbitrarias y frágiles. Al exigir que cada palabra clave se ejecute y se valide en el sistema vivo mediante execute_step antes de inscribirla en el archivo .robot, rf-generator garantiza suites de pruebas que pasan desde el momento de su creación.
- Sesión activa demostrada: no se escribe ningún código sin una demostración previa sobre la aplicación de destino.
- Cero pruebas fantasma: erradicación definitiva de las pruebas falsas que fallan en su primera ejecución en CI.
¿Cómo repara rf-healer las pruebas sin ocultar errores reales?
rf-healer limita estrictamente sus correcciones a la capa de adaptación (resources/page_objects/). Tiene formalmente prohibido modificar el cuerpo de la prueba, suprimir pasos o alterar las aserciones esperadas. Si constata que el propio recorrido de negocio ha cambiado o que surge una anomalía funcional, concluye con application_defect o needs_human y alerta al equipo.
- Perímetro protegido: ajuste quirúrgico de los localizadores sin debilitar nunca las verificaciones.
- Retroalimentación honesta: traspaso inmediato al ingeniero de QA en cuanto la regla de negocio ha divergido.
¿Cómo se articulan rf-test-agents, SAPFX y CabrIA?
rf-test-agents es la matriz metodológica de código abierto de AI Cabra. SAPFX retoma esta base universal para añadirle la percepción nativa de SAP GUI Win32 y Fiori UI5. CabrIA aporta el modelo de IA soberano MoE 35B y la base de conocimiento RAG qa-brain para pilotar estos agentes con total autonomía, on-premise o en una nube soberana (Francia, UE).
- rf-test-agents: estándar universal abierto y motor multiagente determinista (Apache 2.0).
- SAPFX y CabrIA: verticalización de ERP críticos e inteligencia empresarial 100 % soberana.
¿Qué es el Spec-Test-Driven Development (STDD) que aplica rf-test-agents?
rf-test-agents aplica el Spec-Test-Driven Development: la especificación es una visión de conjunto en lenguaje humano, estructurada o no (objetivo de negocio, historia de usuario, escenario BDD, archivo de prueba existente); el planner la confronta con el sistema vivo y redacta su versión observada en specs/, que guía la prueba; la prueba, generada paso a paso en sesión activa y sellada con la huella SHA256 de su plan, guía el desarrollo de la capa de automatización. Una capacidad que falta se añade en resources/ (o en la biblioteca de una vertical como SAPFX u ODOOFX), nunca como un rodeo dentro de una prueba. La versión de referencia se observa, no se supone, y está protegida mecánicamente.
Acelere su Quality Engineering con agentes autónomos
¿Desea desplegar rf-test-agents en sus aplicaciones críticas o integrar un orquestador multiagente en sus fábricas de software? Hable directamente con nuestro equipo técnico.
- Un intercambio técnico, no comercial
- Código abierto con licencia Apache 2.0
- Despliegue 100 % on-premise o en una nube soberana (Francia, UE)