Audit des tests OxideTerm

Que fait Audit des tests OxideTerm ?

Maintenez une protection utile contre les régressions au niveau qui possède le comportement. Utilisez la plus petite revue qui résout la modification demandée ; jugez les résultats en fonction des contrats préservés et des erreurs détectées, pas du nombre de tests ou de lignes supprimées.

Lisez le fichier AGENTS.md applicable. Exécutez les commandes depuis la racine du dépôt. La matrice de vérification et le guide de test définissent les vérifications spécifiques au projet ; cette compétence fournit les décisions de qualité des tests.

Choisir la portée

• Écrire ou modifier un test : appliquez les questions de rédaction à ce comportement et examinez sa couverture existante la plus proche.
• Diagnostiquer un échec : établissez pourquoi le test a échoué et si l'implémentation, l'attente, le fixture ou l'environnement est erroné avant de modifier.
• Auditer des tests existants : examinez le module ou le comportement demandé et enregistrez les preuves pour chaque modification proposée. Étendez l'audit à un sous-système entier uniquement si cette portée a été demandée. Utilisez le même standard de preuve pour chaque lot.

Créer ou invoquer cette compétence n'autorise pas un nettoyage général, des sous-agents, des commits, des pushs ou des PRs. Respectez l'autorisation existante de l'utilisateur et toute limite de révision uniquement. Lorsque les modifications sont déjà autorisées et que les preuves sont suffisantes, procédez sans un autre tour d'approbation.

Questions de rédaction

Avant d'ajouter ou de modifier un test, identifiez :

1. Le comportement observable ou le contrat indépendant protégé.
2. Une régression plausible et l'assertion particulière qui échouerait.
3. Ce que la couverture existante la plus proche manque. Étendez cette couverture lorsque cela est approprié ; un autre niveau nécessite un risque d'intégration, de protocole ou de cycle de vie distinct.
4. Si le test nécessiterait une exportation de production, un commutateur, un wrapper ou un crochet d'injection qui n'a aucun appelant métier. Préférez tester à la frontière de propriété existante.

Utilisez des valeurs attendues indépendantes de l'implémentation. Les fixtures doivent distinguer le comportement correct du bogue probable : incluez des candidats exclus lors du test de filtres, des clés de tri différentes lors du test de tri, et une entrée sensible réelle lors de la vérification du masquage. Un aller-retour de champ de constructeur, un résultat non vide ou un mock qui effectue le comportement en cours d'assertion est une preuve insuffisante du workflow prévu.

Les helpers de test et les fixtures peuvent légitimement être réservés aux tests. Le problème est de déformer les API de production ou de maintenir un comportement de production obsolète uniquement pour les tests.

Diagnostiquer un test défaillant

Lisez le test complet, ses entrées, le chemin de production, la couverture voisine et l'historique des modifications pertinent. Pour CI, identifiez le commit défaillant, le job, le nom du test et l'assertion ; un code de sortie non nul générique n'est pas une cause racine. Inspectez la source ou les types des dépendances lorsque l'affirmation dépend de leur comportement.

Classez l'échec à partir des preuves :

• Régression produit : le contrat prévu est toujours valable. Reproduisez l'échec et réparez l'implémentation propriétaire dans la portée autorisée.
• Attente obsolète : l'historique et le contrat actuel montrent un changement de comportement intentionnel. Mettez à jour le comportement attendu tout en conservant la protection pour les formats et API de version publiée pris en charge.
• Test ou fixture défectueux : le cas n'exerce pas sa condition revendiquée, repose sur un état accidentel ou échoue pour une raison non liée. Réparez la configuration et les assertions à la véritable frontière.
• Échec d'environnement : la compilation, les dépendances, les ressources, la plateforme ou les fixtures externes empêchent le test du comportement. Signalez cette limitation ; ne la réinterprétez pas comme un test réussi ou obsolète.

Un échec de base n'est pas une raison pour supprimer un test. Pour une correction de bogue, démontrez l'échec prévu avant la réparation et le succès après. Réutilisez les preuves CI valides ou une base de référence locale capturée lorsqu'elles prouvent le même échec ; n'effectuez pas de vérifications coûteuses uniquement pour la cérémonie.

Par exemple, le test du plugin .oxide doit distinguer la validation sans mot de passe de l'aperçu d'importation déchiffré. La réponse de validation du format chiffré ne doit pas révéler de métadonnées ; l'aperçu contenant le mot de passe doit toujours contenir les noms de description et de connexion explicitement attendus. La mise à jour de ces assertions préserve le contrat sans un autre test de déchiffrement de bas niveau au niveau du plugin.

Auditer avant de modifier

Lisez chaque candidat en entier, y compris les lignes de paramètres. Tracez son point d'entrée de production, ses appelants, les dépendances pertinentes, les implémentations sœurs et les tests qui se chevauchent. Vérifiez l'historique pour la raison de son existence et le routage CI pour savoir quelles vérifications sont réellement exécutées.

Utilisez un enregistrement de preuve compact pour les modifications proposées, dans la réponse de travail sauf si un rapport sauvegardé a été demandé :

Test et emplacement	Comportement et échec crédible	Décision	Preuve restante ou réparée	Validation
Nom exact du test et chemin	Ce que les assertions peuvent détecter	Conserver / Corriger / Consolider / Supprimer	Test nommé ou frontière, avec historique pertinent	Commande ciblée ou scénario manuel

• Conserver : il protège indépendamment un contrat significatif.
• Corriger : le comportement est important, mais l'entrée, l'assertion, le nom ou le résultat attendu est erroné ou trop faible.
• Consolider : déplacez les assertions distinctes dans le test principal nommé avant de supprimer la configuration ou le cas en double.
• Supprimer : nommez la preuve restante la plus forte, ou démontrez que le comportement n'a plus de contrat pris en charge. L'incertitude signifie enquêter ou conserver.

Pour le code de production supprimé avec un test, identifiez également ses appelants non test et pourquoi le code est obsolète. Recherchez des références avant de supprimer un helper, une exportation, une fonctionnalité ou un fixture. Ne faites pas de simplifications non liées dans le cadre de l'audit.

Modèles à étudier

• Le test répète le texte source de l'implémentation, la forme d'appel privée ou la représentation interne exacte, et échoue après un refactoring préservant le comportement.
• Plusieurs niveaux appellent le même helper avec des entrées équivalentes et répètent ses assertions sans exercer leur propre intégration.
• Un fixture préorganise l'ordre de rappel, la notification d'achèvement ou le résultat persistant que le véritable propriétaire devrait produire.
• Un test de rejet est rejeté par la validation des paramètres avant d'atteindre la vérification des autorisations qu'il prétend tester.
• Un test de concurrence, d'annulation ou de réveil ne vérifie qu'un indicateur final sans créer le travail concurrent ou l'attente.
• Une assertion de succès ne vérifie que Ok, Some, la longueur ou la non-vacuité alors que le contenu, l'identité, l'ordre ou un effet secondaire durable est le contrat.

Ce sont des signaux d'investigation, pas des règles de suppression automatiques. Préservez les valeurs par défaut de sécurité indépendantes, les octets de protocole, les formats de persistance et de migration, les API de plugins, le comportement de la plateforme, le packaging, l'internationalisation et les contraintes d'architecture. L'inspection statique peut être utile lorsqu'elle protège un contrat réel et survit à un renommage non pertinent. Une exécution lente seule ne rend pas un test redondant.

Frontières OxideTerm

Comportement	Frontière de vérification préférée
Parsing, normalisation des paramètres, sérialisation ou fusion de données	Crate de domaine propriétaire avec valeurs attendues explicites et exemples de formats pris en charge
Partage de nœuds SSH, SFTP, transfert, reconnexion ou hôtes de rebond	Propriétaire d'exécution avec enregistrement, annulation et nettoyage du consommateur réel ; voir propriété d'exécution
Pages mixtes, focus, popups ou résultats d'interface utilisateur tardifs	Contexte de test GPUI existant et entité de fonctionnalité ; IME natif, fenêtre et comportement GPU nécessitent toujours une validation hôte
Adaptateur de plugin, MCP ou CLI	Répartition réelle et données renvoyées, autorité, identité cible ou effet secondaire ; évitez de rejouer le helper de domaine seul
Masquage et durée de vie des identifiants	Entrée de secret synthétique à travers la frontière de sortie ou de propriété pertinente ; voir données sensibles
Packaging et scripts de dépôt	Tests de script existants ou le contrat de simulation réelle sélectionné par la matrice de vérification

Pour un test de nœud partagé, fermer un terminal doit laisser un autre consommateur réel utilisable. Pour la gestion de résultats obsolètes, fournissez un achèvement ancien après que le propriétaire a changé. Utilisez des fixtures existantes et une synchronisation pilotée par événements ; les attentes arbitraires et les tentatives supplémentaires n'établissent pas ces conditions.

Valider et terminer

Terminez les modifications de source/test pertinentes avant de lancer leur exécution de test. Gardez le checkout stable pendant cette exécution.

1. Lancez le test ciblé ou le module, par exemple cargo test -p <crate> <test_filter>. Utilisez la cible et la plateforme qui le possèdent réellement ; les tests de bureau sont dans la cible binaire oxideterm-native de oxideterm-gpui-app. L'agent distant autonome utilise --manifest-path agent/Cargo.toml.
2. Lisez le résultat et vérifiez que les tests prévus ont réellement été exécutés. Une commande réussie avec zéro test correspondant n'est pas une preuve. Après une suppression ou un déplacement, lancez la couverture restante nommée et toute vérification d'intégration affectée distincte.
3. Lancez cargo fmt --check et git diff --check pour les modifications Rust. Ajoutez les vérifications de crate, les tests de script, l'audit de locale ou les workflows manuels selon la matrice de vérification. Réutilisez les résultats jusqu'à ce que des modifications pertinentes ou de nouvelles preuves les invalident.
4. Examinez le diff final et l'état. Vérifiez qu'aucun comportement unique n'a disparu, qu'aucune assertion n'a été affaiblie pour masquer un échec produit et qu'aucun travail non lié n'a été modifié.

Utilisez une mutation délibérée uniquement lorsque nécessaire pour résoudre un doute concret sur une assertion. Gardez-la isolée du travail utilisateur, restaurez la source exacte ensuite et ne l'exigez pas pour chaque test. Les audits à l'échelle du sous-système doivent concilier les cas supprimés avec leurs tests restants nommés avant d'exécuter les suites affectées finales.

Signalez la décision, le comportement toujours protégé, les vérifications réellement exécutées et toute frontière non vérifiée importante. Expliquez la couverture supprimée lorsqu'une suppression a eu lieu. Arrêtez-vous lorsque la portée demandée est terminée ; n'élargissez pas l'audit pour atteindre un objectif de comptage ou de réduction.

Source

Adapté des principes de valeur de test et de preuve de l'audit de test et des directives de campagne d'OpenClaw. L'exécution, la propriété et la validation suivent ici les règles du dépôt OxideTerm.