Preuve de limite utilisateur
Une allégation de comportement visible par l’utilisateur est prouvée en atteignant la limite de production la plus externe affectée par l’allégation et en vérifiant le résultat qu’un utilisateur observe. Les vérifications unitaires, de composant et de compilation restent utiles, mais elles ne prouvent pas à elles seules un chemin de commande, terminal, navigateur, canal, démon, paquet ou service externe.
Utilisez la plus petite preuve crédible qui atteint la limite modifiée. Un test automatisé ciblé est préférable lorsqu’il exerce cette limite de manière fiable. N’ajoutez des preuves manuelles ou spécifiques à l’environnement que lorsque l’incertitude restante dépend d’un terminal réel, d’un navigateur, d’un système d’exploitation, d’un gestionnaire de paquets, d’un service tiers, d’un échange d’identifiants, d’une reconnexion ou d’un effet de bord. Réservez un test en conditions réelles au niveau full-stack avec service externe réel défini dans Testing.
Choisissez la limite
- Indiquez l’action de l’utilisateur et le résultat observable décrit dans la PR.
- Nommez la limite de production la plus externe affectée par la réclamation : process, terminal, local or remote transport, HTTP or browser, channel API, provider API, approval front door, execution wrapper, lifecycle owner, installer, or package.
- Identifiez les preuves automatisées existantes qui atteignent cette limite sur le head actuel.
- Ajoutez uniquement les preuves nécessaires pour la partie non couverte de l’affirmation.
Actualisez les décomptes CI requis lorsqu’ils atteignent la limite indiquée. Consultez CI & Actions pour connaître la couverture requise actuelle et les lacunes justifiant des éléments de preuve supplémentaires.
Modifications de la présentation visuelle
Toute modification du texte rendu, de la mise en page, de l’espacement, de l’alignement, du retour à la ligne, du rognage, de la couleur, du focus, de la sélection, du comportement adaptatif ou d’un autre état visible doit être étayée par des éléments issus de l’interface réellement prise en charge. Testez l’état modifié sur une révision identifiable dans zerocode, le tableau de bord web, l’application de bureau, une CLI ou une TUI interactive, un programme d’installation ou toute autre interface concernée. Consignez les dimensions du terminal ou de la fenêtre d’affichage et incluez une ou plusieurs captures d’écran respectueuses de la vie privée montrant le contenu modifié avec suffisamment d’éléments de mise en page environnants pour permettre d’en évaluer le résultat.
Une capture d’écran générée par l’automatisation est acceptable lorsqu’elle restitue l’interface de production dans le périmètre revendiqué. Les assertions sur les chaînes, les instantanés limités au composant et les tests du moteur de rendu au niveau des utilitaires restent des éléments utiles de preuve de non-régression, mais ils ne remplacent pas la preuve fournie par l’interface réelle. Une capture d’écran ne prouve que l’état visible ; les affirmations relatives aux interactions et aux transitions doivent également s’appuyer sur l’action de l’utilisateur et le résultat observé.
Matrice de vérification
| Surface | Chemin utilisateur et limite | Preuve minimale crédible | Ajoutez une preuve manuelle ou spécifique à l’environnement lorsque |
|---|---|---|---|
| CLI, y compris le guide de démarrage rapide de la CLI | Un utilisateur exécute la commande fournie, suit les options ou les invites de la CLI, puis observe la sortie, le code de sortie ou l’état enregistré aux limites du processus et du terminal. Le guide de démarrage rapide de la TUI suit la ligne zerocode ; le guide de démarrage rapide web suit la ligne de la passerelle et du tableau de bord. | Un test automatisé ou un script qui lance un binaire exécute la commande réelle avec un répertoire personnel ou de configuration isolé et vérifie le résultat visible par l’utilisateur ; Tests détermine le niveau de la suite. | La revendication dépend des invites interactives, du rendu du terminal, du comportement du shell ou du PATH, des permissions de la plateforme, ou du comportement de mise à niveau à partir de l’état utilisateur existant. |
| zerocode et transport du démon | zerocode se connecte via le socket Unix local ou le canal Windows pris en charge, ou via WSS distant, envoie une vraie requête et affiche ou persiste l’état retourné. | Un test d’intégration ou un test système utilise le client, le serveur et le transport déclaré réels, tout en simulant uniquement les services externes. | L’assertion dépend de la saisie clavier, de la disposition du terminal, des chemins de socket ou des permissions, du TLS ou de l’authentification, du comportement de reconnexion, ou du cycle de vie du processus du démon. |
| Passerelle, API et tableau de bord | Un client franchit la limite HTTP, WebSocket ou SSE et un navigateur ou un consommateur d’API observe la réponse, le flux, le résultat d’authentification ou le changement d’état. | Un test au niveau serveur atteint la route réelle et la pile de middlewares ; les assertions côté navigateur incluent également un test d’interface utilisateur sur ce contrat de route. | La revendication dépend de la mise en page ou de l’interaction du navigateur, du comportement des cookies ou de l’authentification du navigateur, du minutage de la reconnexion, de la présentation en streaming ou d’une contrainte de réseau déployé. |
| Chaînes | Un véritable événement entrant de type canal passe par l’analyse de l’adaptateur et la répartition à l’exécution, puis produit la réponse, le fil, le média, la réaction ou le statut sortant attendu. | Les tests d’adaptateur couvrent les charges utiles des fournisseurs et un test système couvre le chemin entrant-sortant avec le réseau du fournisseur simulé. | L’incertitude concerne le threading côté fournisseur, les règles de mention, les limites de médias, la vérification des webhooks, le comportement de livraison ou un autre contrat indisponible dans les fixtures. Utilisez un compte de test dédié. |
| Fournisseurs et routage des modèles | La configuration utilisateur et une requête sélectionnent le fournisseur et le modèle prévus, puis exposent le flux, la réponse, le repli ou l’erreur attendus. | Un test d’intégration ou système utilise la configuration réelle et le chemin de routage avec un point de terminaison de fournisseur simulé fournissant des réponses fidèles au protocole. | L’incertitude porte sur l’authentification du fournisseur, le comportement du réseau, les particularités du streaming, les limites de débit, la disponibilité des modèles, ou tout autre contrat externe non représenté par le mock. |
| Approbation et exécution des outils | Un opérateur reçoit une demande d’approbation via le CLI modifié, le canal, ACP ou la façade web ; la décision atteint la politique commune ; un appel approuvé s’exécute via le répartiteur ou wrapper de production et expose le résultat, l’accusé de réception, l’événement observateur, le refus ou l’effet de bord attendu. | Testez la nouvelle porte d’entrée d’approbation via le gestionnaire d’approbation commun, puis pilotez le chemin de répartition de production avec un outil de test inoffensif et des fixtures de système de fichiers ou de processus contrôlées. | La revendication dépend de la présentation dans le terminal, le canal ou le navigateur, des permissions du système d’exploitation, d’un programme externe réel, de signaux d’annulation, du matériel, de l’accès réseau ou d’un effet secondaire irréversible. |
| Travail en arrière-plan | Une tâche cron, une exécution SOP, une tâche déléguée ou un sous-agent lancé par le runtime démarre via son véritable responsable du cycle de vie et n’expose que les fonctionnalités de suivi de l’état, de persistance, d’annulation, de nouvelle tentative ou de redémarrage prises en charge par ce chemin. | Faites passer le chemin modifié par le propriétaire et l’interface d’état documentés, au moyen d’une horloge déterministe ou d’un worker contrôlé ; utilisez son magasin configuré uniquement si l’assertion inclut la persistance. | L’affirmation dépend de la planification en temps réel, d’un redémarrage effectif du service, de la supervision des processus, ou d’un environnement de planificateur ou de worker externe. |
| Programmes d’installation, paquets et artefacts de version | Un utilisateur exécute le mode modifié de l’installateur ou installe le paquet généré ou l’archive générée dans un environnement propre, puis lance le binaire installé et observe la version ou la fonctionnalité attendue. | Exercez le point d’entrée modifié : exécutez le script d’installation via le mode concerné, ou extrayez ou installez l’artefact généré et exécutez une commande minimale post-installation dans un environnement cible propre. | La cible est absente de la CI requise ou la revendication dépend des autorisations du gestionnaire de paquets, de l’intégration au shell, de la signature, de la notarisation, de la configuration du service ou du comportement de mise à niveau propre à la plateforme. |
Signaler des preuves
Les éléments probants de validation doivent mentionner la révision testée, l’action de l’utilisateur, l’environnement, le résultat attendu et le résultat observé. Pour les changements de présentation visuelle, incluez les captures d’écran requises ou créez un lien vers celles-ci, et indiquez les dimensions du terminal ou de la fenêtre d’affichage. Ajoutez un lien vers le contrôle automatisé ou incluez la commande exacte et sûre lorsque cela aide un autre évaluateur à le reproduire. Les captures d’écran prouvent l’état visible, et non le comportement caché ; les journaux ne prouvent que le chemin et le résultat qu’ils enregistrent.
Lorsqu’une modification ne peut pas affecter une limite utilisateur et n’a aucune incidence visible pour l’utilisateur, indiquer que la preuve de limite utilisateur supplémentaire n’est pas applicable. Un refactoring préservant le comportement dans un chemin orienté utilisateur doit s’appuyer sur la couverture de régression de limite existante ; il ne nécessite pas de nouvelles preuves manuelles ou spécifiques à l’environnement, sauf si cette couverture présente une lacune identifiée.
Utilisez des données synthétiques et des comptes de test dédiés pour les preuves en conditions réelles. Expurgez les identifiants, jetons, données personnelles et points de terminaison privés. N’agissez pas sur des comptes de production, des effets de bord irréversibles ou des opérations externes payantes sans autorisation explicite.