Développer un cadre d’automatisation mobile et corriger les bugs dans le produit, pas en CI

## Placer chaque changement dans le module responsable du comportement Maintenez une carte concise des modules qui indique où le code s’exécute et qui consomme ses artefacts. Séparez au minimum les responsabilités suivantes : - les pilotes exécutés sur l’appareil et les binaires qu’ils génèrent ; - les adaptateurs de plateforme exécutés sur l’hôte et les clients de protocole ; - l’interprétation des commandes, les nouvelles tentatives, le contrôle du cycle de vie et la classification des erreurs ; - les modèles partagés de commandes et de données ; - les interfaces en ligne de commande et celles destinées aux agents ; - les pilotes web, les définitions de formats d’échange, les utilitaires et les tests transversaux. Placez une modification là où le comportement est détenu. L’interaction avec l’appareil et la gestion des dialogues système relèvent des pilotes de plateforme ou des adaptateurs de l’hôte ; les nouvelles tentatives et l’enchaînement des commandes relèvent de l’orchestration ; les structures de requête partagées relèvent des modules de modèle ou de protocole. Ne résolvez pas un problème de propriété dans un module éloigné au seul motif qu’il est plus facile de l’y corriger. Conservez cette carte comme source unique de vérité pour les workflows et les agents spécialisés. Mettez-la à jour lorsque les responsabilités des modules changent afin d’éviter toute divergence dans les instructions en aval. ## Choisir le niveau de test le moins coûteux qui prouve le comportement Utilisez une stratégie de test par niveaux et choisissez par défaut le niveau le moins coûteux capable de prouver le comportement : 1. Des tests unitaires pour les classes isolées, l’analyse, les petits utilitaires et la logique de décision locale. 2. Des tests d’intégration pour l’orchestration des commandes, l’annulation, les moteurs de script, les limites réseau et les interactions entre plusieurs modules pouvant s’exécuter sans appareil. 3. Des tests de bout en bout pour les véritables pilotes, le comportement de l’appareil ou du navigateur, l’intégration au système d’exploitation et les parcours utilisateur complets. 4. Des évaluations de l’interface destinée aux agents pour le comportement du modèle et la correction des outils lorsque le produit expose un protocole destiné à l’IA. Ne déplacez pas un test vers un niveau plus coûteux lorsque des substituts ou des composants exécutés dans le même processus peuvent représenter fidèlement le contrat. À l’inverse, ne remplacez pas des preuves au niveau de l’appareil par des mocks lorsque le risque concerne le comportement de la plateforme. ## Séparer les suites qui doivent réussir de celles qui doivent échouer Séparez les parcours de bout en bout selon le résultat attendu. Une suite positive contient des parcours qui doivent réussir ; tout échec constitue une régression. Une suite négative contient des assertions ou des commandes volontairement invalides et doit échouer de la manière prévue. Le banc de test peut inverser l’interprétation de la réussite pour la suite négative ; l’analyse des artefacts doit donc conserver l’étiquette de la suite. Ne diagnostiquez jamais un résultat négatif attendu comme une régression du produit et n’affaiblissez ni ne réécrivez un parcours négatif uniquement pour le faire réussir. Lorsqu’un processus de diagnostic automatisé consomme des artefacts, limitez-le aux véritables échecs de la suite positive, sauf si son contrat prend explicitement en charge l’analyse des parcours négatifs. Stockez les artefacts dans une hiérarchie prévisible comprenant l’application, la plateforme, la suite et l’identité de l’exécution. ## Réutiliser une seule application de test pour les tests de bout en bout sur toutes les plateformes Utilisez une application de test par défaut pour exercer toute la surface des commandes sur les plateformes prises en charge. Réutilisez les mêmes parcours à deux fins : tests rapides de régression sur les versions actuelles des plateformes et validation de compatibilité sur une nouvelle version du système d’exploitation. Si un comportement est propre à un cadre, ajoutez un espace de travail de test dédié au lieu de déformer l’application par défaut. Donnez à chaque espace ses propres parcours et son propre artefact de compilation, et permettez à l’exécution manuelle de se limiter à une application ou à un parcours. Paramétrez le pilote de test selon la plateforme et des entrées d’environnement explicites. Validez les entrées d’exécution avant de mettre en place une infrastructure coûteuse : refusez rapidement les versions système non prises en charge, les espaces de travail absents et les sélecteurs de parcours ambigus. ## Corriger les échecs sur l’appareil dans le pilote, pas par des réglages de CI Lorsqu’un parcours de bout en bout échoue parce qu’un pilote de plateforme ne sait pas gérer le comportement réel de l’appareil, corrigez le pilote, l’adaptateur de l’hôte ou l’application de test réellement exécutée par les utilisateurs. Ne masquez pas cette lacune en ajoutant à la chaîne d’intégration continue des réglages d’émulateur, des commandes shell, des ajustements de ligne de commande ou une préconfiguration. Les modifications de la chaîne d’intégration conviennent à sa propre structure : matrices, conservation, déclencheurs, entrées d’exécution validées ou exceptions d’infrastructure limitées et documentées. Elles ne remplacent pas le comportement du produit. Appliquez la même règle à la validation d’une nouvelle version du système d’exploitation. Un parcours qui ne réussit qu’après une préparation propre à l’intégration continue révèle encore un défaut de compatibilité du produit, sauf si cette préparation constitue un prérequis explicitement imposé à l’utilisateur. ## Classer les erreurs selon qu’on peut réessayer, et toujours nettoyer les fichiers temporaires Utilisez une exécution asynchrone structurée avec des répartiteurs ou des exécuteurs explicites. Réservez les ponts bloquants aux points d’entrée de l’application. Classez les échecs exposés afin que l’orchestration puisse distinguer les conditions pouvant être retentées des erreurs définitives, au lieu de tout retenter uniformément. Faites passer les fichiers et répertoires temporaires par un gestionnaire de ressources propriétaire de leur cycle de vie. Construisez-le près de l’opération qui détient les ressources, allouez celles-ci par son API et fermez-le dans un chemin `finally` afin que le nettoyage récursif ait lieu après une réussite, un échec ou une annulation. Ne contournez pas le gestionnaire de ressources par des appels directs de création de fichiers temporaires. Les fichiers non gérés s’accumulent dans les processus de longue durée et rendent les échecs plus difficiles à reproduire. Lorsqu’aucun appareil n’est nécessaire, testez l’annulation, les délais d’expiration, le comportement du superviseur et le nettoyage au moyen d’une orchestration réelle et de pilotes substituts déterministes. ## Tester séparément les outils pour agents et le comportement du modèle Lorsque l’application en ligne de commande expose également un serveur destiné aux agents, maintenez deux familles de tests distinctes : - des tests fonctionnels des outils qui vérifient les requêtes, les réponses, la configuration des appareils et le comportement en cas d’échec ; - des évaluations du comportement du modèle qui mesurent si un agent sélectionne et utilise correctement les outils. Utilisez des cas d’évaluation déclaratifs et des scripts de configuration propres à chaque plateforme afin de rendre la couverture reproductible. Exécutez des tests d’outils rapides pour les modifications ordinaires de l’implémentation ; exécutez des évaluations de modèle plus lentes lorsque changent les prompts, les descriptions d’outils, les schémas, le routage ou le comportement visible par l’agent. Ne considérez ni une note du modèle comme une preuve du fonctionnement de l’outil sous-jacent, ni un test fonctionnel de l’outil comme une preuve qu’un agent l’utilisera correctement. Les deux contrats exigent leurs propres preuves. ## Reconstruire les binaires générés au lieu de les modifier à la main Considérez les binaires de pilotes versionnés, les exécuteurs empaquetés, les sommes de contrôle et les autres fichiers dérivés comme des résultats de générateurs. Ne les modifiez jamais manuellement. Exécutez la tâche de compilation ou le finaliseur responsable et consignez les artefacts obtenus avec la modification source qui les a produits. Avant de terminer : 1. Confirmez que la modification se trouve dans le module propriétaire du comportement. 2. Exécutez le niveau de test suffisant le moins coûteux, puis tout niveau plus large directement affecté. 3. Interprétez les suites positives et négatives selon leurs contrats. 4. Vérifiez que les ressources temporaires sont fermées après une réussite, un échec et une annulation. 5. Régénérez les artefacts dérivés par le chemin de compilation officiel. 6. Confirmez que les modifications d’intégration continue décrivent la structure de l’infrastructure au lieu de masquer des défauts du produit. Maintenez synchronisés la documentation des workflows, l’organisation des applications de test et les notes de propriété des modules afin que les contributeurs et les agents automatisés ultérieurs respectent les mêmes limites.