ODOOFX · Automatización de pruebas de Odoo para Robot Framework
ODOOFX (paquete robotframework-odoofx) es una biblioteca de código abierto para Robot Framework dedicada a la automatización de pruebas de Odoo Community y Enterprise: la API RPC, la interfaz web y el ORM, con los cinco agentes y el método Spec-Test-Driven Development ya probados en SAP. La versión 0.2.0 está en PyPI: sus dos canales, la API RPC (XML-RPC y JSON-2) y el cliente web (inicio de sesión, navegación, lectura de las vistas, entrada y guardado de formularios, botones de acción), están probados en vivo en Odoo 16 y 19. Esta página dice lo que existe, lo que se está construyendo y en qué orden.
Un ERP que cambia cada año, pruebas que deben seguirle el ritmo
Odoo publica una versión principal al año, cada empresa lo enriquece con módulos y personalizaciones, y sus API evolucionan. Una herramienta de prueba genérica ve páginas web; ODOOFX quiere ver modelos, campos y estados de flujo de trabajo.
Una versión principal al año
Los menús, las etiquetas y las vistas cambian de una versión a otra. ODOOFX apunta a una única base de código con detección de versión, en lugar de una suite de pruebas por versión que haya que mantener en paralelo.
Módulos y personalizaciones propios de cada empresa
Ventas, inventario, contabilidad, módulos de la comunidad y desarrollos internos: los agentes parten de la instancia real (modelos, campos, vistas) y no de una descripción genérica de Odoo.
API que cambian de forma
Odoo 19 declara obsoletos /xmlrpc y /jsonrpc en favor de la API JSON-2, con una retirada anunciada en la versión 22. El canal RPC de ODOOFX ya admite ambas vías: XML-RPC hasta Odoo 18, JSON-2 a partir de Odoo 19.
Tres canales para actuar y verificar
El mismo principio que SAPFX, que unifica SAP GUI, Fiori y las API: una prueba actúa por el canal más fiel al recorrido del usuario y verifica por el canal más directo.
Interfaz web
El cliente web de Odoo pilotado por la biblioteca Browser (Playwright): inicio de sesión con prueba del destino, navegación por los menús mediante identificadores externos, lectura de las vistas, entrada y guardado de formularios (texto, fechas, listas de selección por código, casillas, relaciones, líneas), botones de acción y control de los estados. Es el recorrido que vive el usuario. Operativo en la 0.2.0: escrituras en pantalla cerradas por defecto y registradas, y un formulario a medio rellenar nunca se guarda por accidente. Por llegar: los botones que abren un asistente, las líneas de sección y de nota, la supresión de línea.
API RPC
Crear, leer, modificar, buscar y eliminar registros, llamar a un método de negocio (confirmar, cancelar) sin pasar por la pantalla. Operativo desde la 0.1.0: escrituras cerradas por defecto y registradas, destino demostrado (URL, base de datos, versión) antes de cualquier escritura.
Introspección ORM
Leer los campos de un modelo con su tipo y sus relaciones, los modelos cuyo nombre contiene un texto, el estado de un módulo, los códigos de un campo de selección, el estado de flujo de trabajo de un registro y el identificador que hay detrás de un identificador externo: en la 0.2.0, probado en lectura en Odoo 16 (XML-RPC) y 19 (JSON-2). Es lo que leerán los agentes para redactar una especificación.
La aplicación móvil de Odoo (Appium) queda fuera del alcance de la primera versión.
Lo que la 0.2.0 automatiza desde hoy
Tres usos cubiertos por la versión publicada, por la API y en pantalla, probados en Odoo 16 y 19.
Pruebas de regresión por la API
Reproducir un flujo de negocio (presupuesto, confirmación, envío, cancelación) por XML-RPC o JSON-2, o en pantalla en el cliente web (entrada de un contacto, entrada y confirmación de un presupuesto con su botón), y verificar los códigos de estado, sea cual sea el idioma de la interfaz. La misma capa de negocio, neutra respecto a la versión, se ejecuta en Odoo 16 y 19.
Datos de prueba limpios y trazables
Cada registro creado lleva un marcador de ejecución; cada escritura queda registrada (prevista, hecha, fallida, desconocida) y su desaparición se demuestra sobre el registro identificado. Las escrituras siguen cerradas mientras la conexión no las autorice.
Permisos de acceso y prueba del destino
Comprobar que un usuario pertenece, o no, a un grupo designado por su identificador externo, y demostrar la URL, la base de datos y la versión de Odoo antes de cualquier escritura: dos versiones de Odoo pueden convivir sin riesgo de confusión.
Cinco agentes, un método común
ODOOFX aplica el Spec-Test-Driven Development definido en rf-test-agents: la especificación, escrita en lenguaje humano y confrontada con la instancia viva de Odoo, guía la prueba; la prueba guía la biblioteca. La misma lógica que TDD, un ladrillo antes: la spec, verde por defecto en teoría, se confronta con el sistema real antes de escribir ningún test. Los agentes llevaron a cabo la primera campaña (dos planes observados en Odoo 16 y 19, quince suites RPC generadas y ejecutadas en vivo, una revisión independiente de solo lectura y una revisión ISTQB) y después una segunda: ocho suites web y ORM ejecutadas en vivo, seis de ellas revisadas por la revisión independiente y la revisión ISTQB. Viven en un repositorio de taller privado, con un plugin de rf-mcp y la capa odoofx-mcp; PyPI y el repositorio público entregan la biblioteca.
odoo-planner
Confronta la especificación humana (objetivo, historia de usuario, escenario BDD, suite existente) con la instancia real: vistas, modelos y campos ORM, estados de flujo de trabajo. Redacta su versión observada en specs/, revisada por una persona.
odoo-generator
Produce la suite de Robot Framework a partir del plan, con cada paso ejecutado en vivo antes de escribirse, y la sella con la huella SHA256 del plan: un plan modificado sin regenerar la suite hace fallar el control.
odoo-healer
Repara la capa resources/, nunca la prueba ni sus aserciones. Presupuestos fijados (2 candidatos, 20 llamadas, 900 segundos) y cinco veredictos, entre ellos application_defect cuando es Odoo el que ha cambiado.
odoo-istqb
Diseña planes y casos de prueba ISTQB reproducibles, y revisa cada suite generada: trazabilidad de los requisitos, valores límite, transiciones de estado, independencia y mantenibilidad, con un veredicto fechado.
odoo-verifier
Revisión independiente de solo lectura: fidelidad de la ejecución, exactitud de los veredictos, cobertura cumplida respecto a lo prometido en el plan. No escribe nada y no puede ser influido.
Datos de prueba válidos que no salen del equipo
Tres necesidades concretas de las pruebas de ERP, inscritas en el backlog y definidas el 23 de septiembre de 2026. Nada de ello está implementado todavía.
Identificadores de negocio válidos por construcción
SIREN y SIRET (identificadores franceses de empresa), número de IVA intracomunitario e IBAN ficticios pero válidos, proporcionados por un paquete de Robot Framework compartido con SAPFX. Una semilla registrada permite reproducir un fallo con el mismo dato.
Presupuestos, facturas y albaranes leídos en PDF
El PDF se obtiene mediante la ruta de informes de Odoo con la sesión autenticada y después se verifica su texto. Un PDF sin capa de texto falla indicándolo, nunca con una lectura vacía.
Un buzón de prueba local
El servidor SMTP saliente de Odoo apunta a un buzón Mailpit en un contenedor local, leído mediante su API: espera acotada de un mensaje, contenido, enlaces. Nunca un buzón público.
De la base del proyecto a la versión 1.0, en este orden
Estado a 13 de octubre de 2026. Los plazos son objetivos, no compromisos.
Base del proyecto · implantada
Repositorio público, licencia Apache 2.0, integración continua, control de redacción, memoria del proyecto y definición de los cinco agentes. Dos instancias de prueba de Odoo (16 y 19) están aprovisionadas con sus datos de demostración.
Canal RPC de la biblioteca · entregado en la 0.1.0
Lectura, escritura cerrada por defecto y registrada, llamada a métodos de negocio, prueba del destino; XML-RPC hasta Odoo 18, JSON-2 a partir de Odoo 19. Las treinta primeras keywords documentadas.
Primera campaña en vivo · realizada el 1 de octubre de 2026
El presupuesto de venta, del plan observado a la suite ejecutada: 15 suites RPC y 65 pruebas en Odoo 16 y 19 (creación, confirmación, envío, cancelación y vuelta atrás, permisos, producto almacenable), generadas por los agentes y revisadas por una revisión independiente.
Distribución · 0.1.0 el 5 de octubre de 2026, 0.2.0 el 13 de octubre de 2026
Paquete robotframework-odoofx en PyPI (0.1.0 el 5 de octubre, 0.2.0 el 13 de octubre), documentación de las keywords en línea y repositorio público sincronizado.
Canal web e introspección del ORM · entregados en la 0.2.0
Mediante la biblioteca Browser: inicio de sesión con prueba de la base de datos y de la serie, navegación por identificadores externos de menús, lectura de las vistas y de los registros, entrada y guardado de formularios (fechas, listas de selección, casillas, relaciones, líneas), botones de acción, cierre de sesión; en lectura, los campos, las relaciones, los modelos y los estados de los módulos por RPC. 69 keywords documentadas, 68 con un ejemplo reejecutado en Robot Framework. Segunda campaña: ocho suites web y ORM, 52 pruebas ejecutadas en vivo en Odoo 16 y 19 del 8 al 13 de octubre de 2026.
Agentes equipados · plugin entregado, el resto por llegar
El plugin de rf-mcp y la capa odoofx-mcp (estado de sesión: conexión RPC, sesión web, formulario sin guardar, registro de escrituras) existen en el taller privado y superaron 19 comprobaciones de 19 de extremo a extremo en Odoo 16 y 19. Por llegar: el estado de un registro por el ORM y una primera reparación de una suite por odoo-healer, que todavía no ha reparado ninguna.
Cobertura del canal web · por llegar
Los botones que abren un asistente, las líneas de sección y de nota, la supresión de línea, los campos numéricos con formato y un producto almacenable introducido en pantalla, cada uno con su prueba en vivo en Odoo 16 y 19 antes de cualquier publicación.
Multiversión e integración continua · por llegar, objetivo: finales de 2026
La detección de versión existe; faltan la adaptación a cada versión, la correspondencia de menús y etiquetas, la medición en Odoo 14, 15, 17 y 18 (hoy solo 16 y 19), instancias Docker descritas en el repositorio y una matriz de CI sobre las versiones objetivo.
Versión 1.0 · objetivo: 2027
Firmas estabilizadas, funciones admitidas documentadas versión por versión, versiones objetivo medidas. Los plazos son objetivos, no compromisos.
Instalar desde PyPI, con un solo comando
El paquete robotframework-odoofx se instala desde PyPI (Python 3.10 o superior, Robot Framework 7.4 o superior) y la documentación de sus 69 keywords está en línea. Las credenciales pasan por la línea de comandos, nunca por una suite.
# Instalar la biblioteca desde PyPI
pip install robotframework-odoofx
# Opción: la biblioteca Browser, para el canal web
pip install "robotframework-odoofx[web]"
rfbrowser init # navegadores de Playwright, una sola vez*** Settings ***
Library OdooFxLibrary
*** Test Cases ***
Leer el estado de un presupuesto
Connect To Odoo http://localhost:8069 mi_base admin ${PASSWORD} channel=xmlrpc
Assert Quotation Status Is sale S00004
[Teardown] Disconnect From Odoo
# Ejecución: el secreto pasa por la línea de comandos
# robot -v "PASSWORD: Secret:<secret>" leer_presupuesto.robotComprender ODOOFX
Las respuestas breves a las preguntas que nos hacen sobre el estado del proyecto, las versiones objetivo y el lugar de ODOOFX en el ecosistema de AI Cabra.
¿En qué punto está ODOOFX hoy?
ODOOFX está en fase alfa, versión 0.2.0, publicada en PyPI el 13 de octubre de 2026 (la 0.1.0 es del 5 de octubre). Dos canales funcionan y están probados en vivo en Odoo 16 y Odoo 19. El canal RPC: lectura, escritura cerrada por defecto y registrada, prueba del destino, por XML-RPC hasta Odoo 18 y por la API JSON-2 a partir de Odoo 19. El cliente web, mediante la biblioteca Browser: inicio de sesión con prueba del destino, navegación por identificadores externos de menús, lectura de las vistas, entrada y guardado de formularios, botones de acción. Se han ejecutado 23 suites y 117 pruebas en las dos instancias (55 en Odoo 16, 62 en Odoo 19), escritas a partir de planes observados en las instancias. Aún no cubiertos: los botones que abren un asistente, las líneas de sección y de nota, la supresión de línea. No se reivindica ningún resultado en una instancia de cliente.
- Código abierto desde el primer día: el repositorio público refleja el estado real, sin escaparate.
- Cifras medidas, no anticipadas: cada resultado publicado indica su alcance y sus límites.
¿Qué versiones de Odoo cubre ODOOFX?
Odoo Community y Enterprise, desde la versión 14, con una única base de código y detección de versión en lugar de una rama por versión. El desarrollo se apoya en Odoo 16, último cliente web histórico, y en Odoo 19, la versión más reciente: son las dos versiones probadas hasta hoy. Odoo 19 declara obsoletos los puntos de entrada /xmlrpc y /jsonrpc en favor de la API JSON-2, con una retirada anunciada en la versión 22: la biblioteca usa XML-RPC hasta Odoo 18 y JSON-2, con una clave de API, a partir de Odoo 19.
- Dos generaciones de referencia: Odoo 16 y Odoo 19 en contenedores locales.
- API anticipada: JSON-2 en servicio antes de la retirada de los antiguos puntos de entrada.
¿Por qué probar Odoo mediante la API y el ORM además de la interfaz?
La interfaz demuestra el recorrido del usuario, pero es lenta y sensible a los cambios de visualización. Las llamadas RPC preparan los datos y verifican el estado real de los registros sin pasar por la pantalla; la introspección ORM proporciona a los agentes los modelos, los campos y los estados de flujo de trabajo reales en lugar de suposiciones. Así, una misma prueba puede actuar mediante la interfaz y verificar mediante la API.
- Actuar por la pantalla, verificar por la API: un control que no depende de la visualización.
- Especificaciones basadas en la instancia: los agentes leen el ORM, no adivinan.
¿Cómo se articula ODOOFX con SAPFX y rf-test-agents?
rf-test-agents define el método común: el Spec-Test-Driven Development y el contrato de los cinco agentes. SAPFX lo aplica a SAP y ODOOFX a Odoo, sin bifurcarlo: una mejora del método descubierta en Odoo sube a rf-test-agents y luego vuelve a las demás verticales. ODOOFX aporta lo que es propio de Odoo: percepción ORM, canales RPC, lectura de las vistas y de los estados de flujo de trabajo.
- Un método, varios ERP: los mismos agentes razonan del mismo modo sobre SAP y sobre Odoo.
- Ninguna dependencia de código: cada vertical conserva su propio ciclo de vida.
Resultados medidos y alcance de la validación
Probar Odoo con Robot Framework a través de la API RPC y de la interfaz web, con introspección del ORM. Revisado el 13 de octubre de 2026. Las fuentes publicadas y las condiciones de medición se detallan a continuación.
- 117 pruebas en vivo en Odoo 16 y 19 23 suites ejecutadas en dos instancias Docker de desarrollo entre el 1 y el 13 de octubre de 2026: 55 pruebas en Odoo 16, 62 en Odoo 19. El flujo RPC del presupuesto de venta (15 suites, 65 pruebas: creación, confirmación, envío, cancelación y vuelta atrás, permisos de un comercial, producto almacenable, casos negativos, ejecutadas el 1 de octubre); el cliente web (exploración de solo lectura, entrada de un contacto, entrada y confirmación de un presupuesto en pantalla) y la introspección del ORM (8 suites, 52 pruebas, ejecutadas del 8 al 13 de octubre). Ninguna instancia de cliente. Ejecuciones internas del 01/10 al 13/10/2026
- 0.2.0 publicada en PyPI Publicada el 13 de octubre de 2026, después de la 0.1.0 del 5 de octubre: pip install robotframework-odoofx, Python 3.10 a 3.14, Robot Framework 7.4 o superior. Instalada desde PyPI en un entorno nuevo, expone sus 69 keywords. Fase alfa: las firmas pueden cambiar todavía antes de la 1.0. Paquete robotframework-odoofx en PyPI
- 69 keywords documentadas Canales RPC y web e introspección del ORM, todos documentados con Libdoc; la 69.ª, Create New Quotation, es un esqueleto que solo avisa. XML-RPC hasta Odoo 18, JSON-2 a partir de Odoo 19; cliente web mediante la biblioteca Browser. No cubiertos: los botones que abren un asistente, las líneas de sección y de nota, la supresión de línea. Documentación de las keywords (Libdoc)
- 68 ejemplos reejecutados en Robot Framework Cada una de las 68 keywords que no son un esqueleto lleva un ejemplo de uso, reejecutado tal como está escrito en Robot Framework contra Odoo 16 el 13 de octubre de 2026 (68 de 68, nada dejado en la instancia). Un registro de huellas impide que un ejemplo cambie sin ser reejecutado. Medición interna, sin instancia de cliente. Reejecución interna del 13/10/2026
- 849 pruebas unitarias Medidas el 13 de octubre de 2026 en el puesto de desarrollo, sin Odoo: verifican la biblioteca contra dobles locales de Odoo, la exportación pública, los controles del repositorio y el registro de ejemplos reejecutados, no una instancia de Odoo. Medición interna del 13/10/2026
- 19 comprobaciones de extremo a extremo con rf-mcp El plugin rf-mcp de ODOOFX y su capa odoofx-mcp, con una herramienta de estado de sesión (conexión RPC, sesión web, formulario sin guardar, registro de escrituras), superaron 19 comprobaciones de 19 a través de las herramientas reales de rf-mcp 0.36, en Odoo 16 y luego en Odoo 19, en solo lectura. Herramientas del taller privado, ausentes del paquete de PyPI. Comprobación interna del 13/10/2026
¿Prueba Odoo, o va a tener que hacerlo?
Actualización de versión, módulos a medida, pruebas de aceptación de un proyecto de integración: hablemos de sus recorridos críticos. Sus casos reales orientan la hoja de ruta de ODOOFX.
- Un intercambio técnico, no comercial
- Sus datos permanecen en Francia