Mcube333/escritor-de-pruebas-appium-java

Escritor de Pruebas Appium Java

Genera pruebas móviles que parecen hechas por un SDET de verdad: un único código base para Android e iOS, seguro para ejecución paralela en múltiples dispositivos, sin sleeps, gestos que funcionan en java-client 9+, e informes Allure que rastrean los IDs de casos manuales. También maneja migraciones de Python a Java, una tarea común en el mundo real que merece hacerse bien y no solo transliterando.

Decide el modo

• Casos manuales → Java: sigue el Flujo de trabajo A.
• Código Python/Appium → Java: sigue el Flujo de trabajo B. Primero lee references/python-to-java-migration.md.
• Crear estructura de proyecto: genera los archivos en references/framework-scaffold.md, adaptados a la aplicación y plataformas del usuario.

Si el usuario comparte archivos existentes de su framework Java (BaseTest, una clase de pantalla, testng.xml, capacidades), respeta sus convenciones por encima de las de referencia.

Flujo de trabajo A: casos manuales → pruebas

1. Normaliza cada caso en: ID, título, prioridad, plataforma(s), precondiciones, datos de prueba, pasos, resultados esperados. Anota pasos específicos de plataforma (botón de retroceso en Android, alerta de permisos en iOS).
2. Pantallas y componentes: una clase por pantalla; widgets reutilizables (navegación inferior, barra de herramientas, hoja inferior) como clases de componente que se componen en las pantallas. Los métodos de pantalla expresan la intención del usuario y llevan Allure @Step("..."). Las acciones de navegación devuelven el siguiente objeto de pantalla.
3. Localizadores — multiplataforma mediante anotaciones en el mismo campo:

   @AndroidFindBy(accessibility = "login-button")
   @iOSXCUITFindBy(accessibility = "login-button")
   private WebElement loginButton;
   

   Prioridad: accessibility id → resource-id de Android / name de iOS → UiAutomator / predicate de iOS o class chain → XPath último (lento en iOS, frágil en todas partes; comenta por qué si se usa). Si no se proporcionó fuente de página, salida de Appium Inspector, o capturas de pantalla, marca las suposiciones con // TODO-VERIFY locator. Si solo se conoce el localizador de una plataforma, escribe ese y deja la otra anotación con un TODO-VERIFY en lugar de copiarlo ciegamente.
4. Pruebas: un @Test por caso, método con nombre basado en comportamiento, @TmsLink con el ID del caso, @Epic/@Feature/@Story/@Severity (P0 → BLOCKER/CRITICAL, P1 → NORMAL, P2+ → MINOR). Variantes de datos → @DataProvider con el ID del caso como primera columna y Allure.link(caseId, "tms", caseId) en el cuerpo. Cada resultado esperado se convierte en una aserción.
5. Estado de la aplicación/dispositivo: menciona los casos que necesitan capacidades no predeterminadas (diálogos de permisos necesitan autoGrantPermissions=false, onboarding necesita instalación limpia / noReset=false, características solo de emulador como huella dactilar) y ponlos en un grupo separado o anota la anulación.
6. Precondiciones: prefiere enlaces profundos (driver.get("myapp://cart") en Android, mobile: deepLink) o configuración mediante API en lugar de secuencias largas de taps. Precondiciones de inicio de sesión mediante API/sesión cuando sea posible.
7. No automatizable tal como está escrito (SMS OTP real, pagos reales, biometría sin soporte de simulador, comprobaciones visuales subjetivas): enumera bajo "No automatizado" con una alternativa (OTP de prueba, pago en sandbox, mobile: enrollBiometric/sendBiometricMatch en simuladores/emuladores, herramienta de comparación visual).

Flujo de trabajo B: migración Python → Java

1. Lee references/python-to-java-migration.md.
2. Mapea primero la estructura (fixtures de conftest → BaseTest/factory, módulos de página → clases de pantalla, parametrize → @DataProvider), luego traduce el código.
3. Corrige anti-patrones en lugar de portearlos: time.sleep → esperas explícitas, TouchAction/MultiAction → Acciones W3C o gestos mobile:, diccionarios de capacidades deseadas → UiAutomator2Options/XCUITestOptions, driver global → ThreadLocal.
4. Mantén la intención de la prueba y las aserciones idénticas. Si la prueba Python afirmaba algo débil (por ejemplo, assert element) u ocultaba fallos (try/except: pass, aserciones dentro de condicionales), corrígelo y menciónalo en la tabla de migración, porque la prueba original quizás nunca pudo fallar.
5. Genera una tabla de migración: Archivo/función Python | Clase/método Java | Cambios más allá de la traducción.

Esperas: explícitas y basadas en condiciones

• La espera implícita es 0. Mezclar esperas implícitas y explícitas causa timeouts impredecibles.
• Nunca uses Thread.sleep. Usa WebDriverWait con ExpectedConditions (visibilityOf, elementToBeClickable, invisibilityOf, textToBePresentInElement, attributeToBe) a través de helpers en BaseScreen.
• Espera a que los cargadores/spinners desaparezcan en lugar de esperar a que pase el tiempo.
• Los tiempos de espera provienen de la configuración, no de números inline.
• Después de una acción que vuelve a renderizar una lista o carrusel, espera una señal que siempre sea verdadera después (hoja cerrada, cargador desaparecido, lista presente, conteo igual al esperado). No esperes a que "el texto del primer elemento cambie": el valor esperado puede ya estar en su lugar y la espera expirará. La espera de BaseScreen ignora StaleElementReferenceException, así que vuelve a consultar dentro de la condición.

Gestos

java-client 9 eliminó TouchAction/MultiAction. Usa:

• Desplazar a elemento: Android AppiumBy.androidUIAutomator("new UiScrollable(...).scrollIntoView(...)"); iOS mobile: scroll con predicateString.
• Deslizar/arrastrar/presión larga: gestos mobile: de plataforma (Android mobile: swipeGesture, longClickGesture; iOS mobile: swipe, touchAndHold) o una secuencia W3C PointerInput en BaseScreen para uso multiplataforma. Consulta references/framework-scaffold.md → Gestos.

Seguridad en paralelo

El driver vive en un ThreadLocal<AppiumDriver> creado por prueba (o por clase si el usuario pide velocidad), siempre se remove() después de quit(). Cada dispositivo paralelo necesita su propio udid y un systemPort único (Android) / wdaLocalPort (iOS) desde los parámetros de testng.xml. Sin drivers estáticos ni estado de elemento estático.

Formato de salida

1. Archivos: archivos completos compilables con imports, cada uno bajo su encabezado de ruta. Si hay más de ~3 archivos o el usuario quiere descargarlos, también escríbelos al disco como una carpeta de proyecto.
2. Tabla de trazabilidad (Flujo A) o tabla de migración (Flujo B).
3. No automatizado / brechas.
4. Necesita verificación: cuenta y lista de localizadores TODO-VERIFY, capacidades asumidas (ruta de la app, paquete/actividad, bundle id), pasos solo de plataforma.

Mantén el texto breve; el código es el entregable.

Confidencialidad

Para trabajo de portafolio/público, usa el paquete com.example (o el del usuario), una app demo pública, y reemplaza cualquier nombre de empresa, IDs de aplicación internos, URLs internas, números de teléfono/correos reales, o nombres de eventos propietarios por otros neutrales. Menciona el reemplazo en una línea.

Archivos de referencia

• references/framework-scaffold.md: pom.xml, configuración, DriverFactory con ThreadLocal + clases Options, BaseTest con captura de pantalla Allure/fuente de página en fallo, BaseScreen con helpers de espera y gestos, testng.xml para dispositivos en paralelo.
• references/python-to-java-migration.md: mapeo lado a lado de modismos Python Appium/pytest a Java/TestNG, más una migración realizada.
• references/example-swaglabs.md: casos manuales → pantallas → pruebas en la app pública de Sauce Labs.