Desarrollar un marco de automatización móvil y corregir fallos en el producto, no en la CI

## Colocar cada cambio en el módulo responsable de ese comportamiento Mantén un mapa de módulos conciso que indique dónde se ejecuta el código y quién consume sus artefactos. Separa, como mínimo, estas responsabilidades: - los controladores del dispositivo y sus binarios generados; - los adaptadores de plataforma del host y los clientes de protocolo; - la interpretación de comandos, los reintentos, el control del ciclo de vida y la clasificación de errores; - los modelos compartidos de comandos y datos; - las interfaces de línea de comandos y las orientadas a agentes; - los controladores web, las definiciones de formatos de comunicación, las utilidades y las pruebas entre módulos. Coloca cada cambio donde se posea el comportamiento. La interacción con el dispositivo y la gestión de diálogos del sistema pertenecen a los controladores de plataforma o a los adaptadores del host; los reintentos y la secuenciación de comandos pertenecen a la orquestación; las formas compartidas de las solicitudes pertenecen a los módulos de modelo o protocolo. No resuelvas un problema de propiedad en un módulo distante solo porque allí resulte más fácil aplicar un parche. Mantén el mapa como fuente única de verdad para los flujos de trabajo y los agentes especialistas. Actualízalo cuando cambien las responsabilidades de los módulos para evitar que las instrucciones derivadas se desvíen. ## Elegir la capa de pruebas más barata que demuestre el comportamiento Usa una estrategia de pruebas por capas y elige de forma predeterminada la capa de menor coste capaz de demostrar el comportamiento: 1. Pruebas unitarias para clases aisladas, análisis, utilidades pequeñas y lógica local de decisión. 2. Pruebas de integración para la orquestación de comandos, la cancelación, los motores de scripts, los límites de red y la interacción entre varios módulos que pueda ejecutarse sin dispositivo. 3. Pruebas de extremo a extremo para controladores reales, comportamiento del dispositivo o navegador, integración con el sistema operativo y flujos completos de usuario. 4. Evaluaciones de la interfaz para agentes cuando el producto exponga un protocolo orientado a la IA, con el fin de comprobar el comportamiento del modelo y la corrección de las herramientas. No asciendas una prueba a una capa más costosa cuando un componente simulado o en proceso pueda expresar el contrato con precisión. Por el contrario, no sustituyas la evidencia a nivel de dispositivo por mocks cuando el riesgo sea el comportamiento de la plataforma. ## Separar las suites que deben pasar de las que deben fallar Separa los flujos de extremo a extremo según el resultado esperado. Una suite positiva contiene flujos que deben aprobarse; cualquier fallo es una regresión. Una suite negativa contiene aserciones o comandos intencionadamente no válidos y debe fallar de la forma prevista. El arnés puede invertir la interpretación del éxito para la suite negativa, por lo que la lectura de los artefactos debe conservar la etiqueta de la suite. Nunca diagnostiques como regresión del producto un resultado negativo esperado ni debilites o reescribas un flujo negativo únicamente para que se apruebe. Cuando un proceso de diagnóstico automatizado consuma artefactos, limítalo a fallos reales de la suite positiva, salvo que su contrato admita explícitamente el análisis de rutas negativas. Guarda los artefactos en una jerarquía predecible que incluya la aplicación, la plataforma, la suite y la identidad de la ejecución. ## Reutilizar una sola aplicación fixture para las pruebas de extremo a extremo en todas las plataformas Usa una aplicación fixture predeterminada para ejercer toda la superficie de comandos en las plataformas compatibles. Reutiliza los mismos flujos con dos fines: pruebas rápidas de regresión en las versiones actuales de las plataformas y validación de compatibilidad en una versión nueva del sistema operativo. Si un comportamiento es específico de un marco, añade un espacio de trabajo fixture dedicado en lugar de distorsionar la aplicación predeterminada. Proporciona a cada espacio sus propios flujos y artefacto de compilación, y permite que la ejecución manual se limite a una aplicación o a un flujo. Parametriza el controlador de pruebas por plataforma y mediante entradas de entorno explícitas. Valida las entradas de ejecución antes de aprovisionar infraestructura costosa: rechaza cuanto antes las versiones de sistema no compatibles, los espacios de trabajo ausentes y los selectores de flujo ambiguos. ## Corregir los fallos del dispositivo en el controlador, no con trucos en la CI Cuando un flujo de extremo a extremo falle porque un controlador de plataforma no pueda gestionar el comportamiento real del dispositivo, corrige el controlador, el adaptador del host o la aplicación fixture que ejecutan los usuarios. No ocultes la carencia añadiendo ajustes del emulador, comandos de shell, modificaciones de línea de comandos o preconfiguración al flujo de CI. Los cambios en el flujo de trabajo son adecuados para su propia estructura: matrices, retención, disparadores, entradas de ejecución validadas o excepciones de infraestructura limitadas y documentadas. No sustituyen el comportamiento del producto. Aplica la misma regla al validar una versión nueva del sistema operativo. Un flujo que solo se aprueba después de una preparación específica de CI sigue indicando un defecto de compatibilidad del producto, salvo que dicha preparación sea un requisito previo explícito para el usuario. ## Clasificar los errores según se puedan reintentar y limpiar siempre los archivos temporales Usa ejecución asíncrona estructurada con dispatchers o ejecutores explícitos. Reserva los puentes bloqueantes para los puntos de entrada de la aplicación. Clasifica los fallos expuestos para que la orquestación distinga las condiciones reintentables de los errores terminales, en vez de reintentar todo de forma uniforme. Gestiona los archivos y directorios temporales mediante un administrador de recursos que posea su ciclo de vida. Créalo cerca de la operación que posee los recursos, asígnalos mediante su API y ciérralo en una ruta `finally` para realizar la limpieza recursiva tras el éxito, el fallo o la cancelación. No eludas el administrador de recursos mediante llamadas directas para crear archivos temporales. Los archivos no gestionados se acumulan en procesos de larga duración y dificultan la reproducción de los fallos. Cuando no se requiera un dispositivo, prueba la cancelación, los tiempos de espera, el comportamiento del supervisor y la limpieza mediante orquestación real con controladores simulados deterministas. ## Probar por separado las herramientas para agentes y el comportamiento del modelo Cuando la aplicación de línea de comandos también exponga un servidor para agentes, mantén dos familias de pruebas distintas: - pruebas de funcionalidad de herramientas que verifiquen solicitudes, respuestas, configuración de dispositivos y comportamiento ante fallos; - evaluaciones de comportamiento del modelo que midan si un agente selecciona y usa correctamente las herramientas. Usa casos de evaluación declarativos y scripts de configuración específicos de cada plataforma para que la cobertura sea reproducible. Ejecuta pruebas rápidas de herramientas para cambios ordinarios de implementación; ejecuta evaluaciones de modelo más lentas cuando cambien los prompts, las descripciones de herramientas, los esquemas, el enrutamiento o el comportamiento visible para el agente. No trates una puntuación del modelo como prueba de que la herramienta subyacente funciona, ni una prueba funcional de la herramienta como evidencia de que un agente la usará correctamente. Ambos contratos necesitan pruebas independientes. ## Regenerar los binarios con la compilación, sin editarlos a mano Trata los binarios de controladores registrados, los ejecutores empaquetados, las sumas de comprobación y otros archivos derivados como resultados de un generador. Nunca los edites manualmente. Ejecuta la tarea de compilación o el finalizador propietario y registra los artefactos resultantes junto con el cambio de origen que los produjo. Antes de terminar: 1. Confirma que el cambio está en el módulo propietario del comportamiento. 2. Ejecuta la capa de pruebas suficiente de menor coste y después cualquier capa más amplia afectada directamente. 3. Interpreta las suites positivas y negativas según sus contratos. 4. Verifica que los recursos temporales se cierren tras el éxito, el fallo y la cancelación. 5. Regenera los artefactos derivados mediante la ruta oficial de compilación. 6. Confirma que los cambios de CI describan la estructura de la infraestructura y no oculten defectos del producto. Mantén sincronizados la documentación de los flujos de trabajo, la distribución de fixtures y las notas sobre propiedad de los módulos para que los colaboradores y agentes automatizados posteriores respeten los mismos límites.