Appium
Convierte pruebas de Appium en Java, Python o JavaScript en casos de prueba de Android de Autonomy con pasos de resultados esperados, sin capabilities, drivers ni locators.
Las pruebas de Appium son pruebas de WebDriver con capabilities de dispositivo. En Autonomy, el dispositivo y el build de la app vienen del entorno, y cada ejecución empieza en un emulador de Android con una instalación limpia. Las pruebas en iOS llegarán pronto. Consulta Móvil y Entornos para los builds.
Prompt
Pega esto en un agente de programación conectado al servidor MCP de Autonomy, desde dentro del repositorio:
Migra las pruebas de Appium de este repositorio a Autonomy con las herramientas MCP de Autonomy.
Preparación
1. Llama a autonomy_project_list y pregúntame qué proyecto usar. Llama a autonomy_environment_list con su projectId y pregúntame en qué entorno ejecutar. Comprueba que tiene un objetivo android para la app; si no lo tiene, avísame antes de crear nada.
2. Llama a autonomy_test_case_list con el projectId. Omite las pruebas que ya cubra un caso de prueba existente.
Para cada prueba
3. Crea UN caso de prueba con autonomy_test_case_create: projectId, name = el título de la prueba, platforms = ["android"] para un platformName Android. Las pruebas en iOS todavía no están disponibles: omite las pruebas de iOS y enuméramelas. Si la misma prueba se ejecuta en las dos plataformas, crea un solo caso de prueba con ["ios", "android"].
4. Escribe cada paso como un resultado esperado: lo que es cierto cuando el paso termina, en palabras sencillas ("Existe una cuenta nueva para un correo nuevo"). Di lo que demuestra la prueba, no cómo: sin toques, deslizamientos, locators, esperas, reintentos ni llamadas a assert. Un paso puede abarcar varias acciones que sirven a un mismo resultado esperado. Usa 12 pasos o menos; divide una prueba más larga en varios casos de prueba.
5. Cada paso es {id, text, attachments[]}. Cada adjunto tiene id, kind y exact. Tipos: account {role}, inbox (sin dirección = una bandeja de entrada nueva por ejecución), phone, file, screenshot, data {label, value} o {label, intent} para datos generados.
6. Nunca escribas una contraseña, un token o una clave en un paso. Por cada cuenta con la que la suite inicia sesión, pídeme que la guarde en el panel (Sign-ins del proyecto, New sign-in) y que te diga su nombre de cuenta; después empieza la prueba con un paso como "El propietario de la tienda ha iniciado sesión" con esa cuenta adjunta. Para otros secretos, propón nombres y referéncialos como {{env.NAME}}; añádelos como valores secretos con autonomy_environment_upsert solo después de que yo esté de acuerdo.
7. Los valores sobre los que trata la prueba (el texto que comprueba un assert, un cupón que debe aplicarse, una entrada que debe rechazarse): un adjunto data con exact: true. El resto de la configuración: {{env.NAME}}.
8. Datos de registro (correos, nombres, contraseñas, números de teléfono): una bandeja de entrada nueva, un adjunto phone y datos generados, nunca un valor fijo.
9. Descarta las capabilities, la configuración del driver, los locators accessibility-id, XPath y UiAutomator, las esperas implícitas y explícitas, resetApp y noReset (cada ejecución empieza con una instalación limpia) y el código que solo cierra diálogos de permisos (el agente gestiona los diálogos). Integra los deslizamientos y los gestos TouchAction en el resultado esperado.
Al terminar
10. Si la suite agrupa pruebas (clases, suites, etiquetas), ofréceme crear un plan de pruebas por grupo con autonomy_test_plan_create.
11. Ejecuta un caso de prueba migrado con autonomy_run_trigger en el entorno que elegí. Síguelo con autonomy_run_get (pasa el último cursor y waitMs) hasta que termine. Para cada paso que no se haya superado, lee autonomy_run_step_actions y cuéntame qué pasó.
12. Termina con una tabla: prueba de origen, ID del caso de prueba, número de pasos y todo lo que no hayas podido trasladar.Equivalencias
| Appium | Autonomy |
|---|---|
| Una prueba | Un caso de prueba. Las pruebas que se ejecutan en las dos plataformas se convierten en un caso de prueba con ambas. |
platformName | La plataforma del caso de prueba: Android. Las pruebas en iOS llegarán pronto. |
Capability app, rutas de builds | El objetivo Android del entorno: un build subido o un enlace de descarga. Consulta Builds móviles. |
| Capabilities de dispositivo y de sistema operativo | No hacen falta. Las ejecuciones usan los emuladores de Android de Autonomy. |
click, sendKeys, accessibility-id, XPath, UiAutomator, class chains | Integrados en el resultado esperado del paso. El agente encuentra los controles. |
Deslizamientos, TouchAction, helpers de scroll | Integrados en el resultado esperado del paso. |
| Asserts sobre el texto de un elemento | El resultado esperado, con el texto esperado como adjunto data marcado como Exact. |
| Esperas implícitas y explícitas, reintentos | Se descartan. |
resetApp, noReset, fullReset | Se descartan. Cada ejecución empieza con una instalación limpia y sin sesión iniciada. |
| Gestión de diálogos de permisos | Se descarta. El agente gestiona los diálogos. |
| Helpers de login | Un paso con la sesión iniciada y un inicio de sesión guardado adjunto como account. |
| Helpers de verificación por SMS o correo | Un adjunto phone o inbox. Consulta Bandejas de entrada y teléfonos. |
| Llamadas a capturas de pantalla | Un adjunto screenshot. |
Consulta el resumen de la migración para ver un ejemplo completo.
¿No lo encontraste?
Selenium
Convierte pruebas de Selenium WebDriver en Java, Python, C# o JavaScript en casos de prueba de Autonomy con pasos de resultados esperados, sin objetos de página ni esperas explícitas.
Maestro
Convierte flujos YAML de Maestro en casos de prueba de Android de Autonomy con pasos de resultados esperados, sin selectores de tapOn ni esperas.