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
Les modifications dont le résultat ou le risque concerne la mise en page, l’espacement, l’alignement, le retour à la ligne, le rognage, la typographie, la couleur, le focus, la sélection, le comportement adaptatif, la composition graphique ou tout autre état sensible à la présentation nécessitent une preuve issue de l’interface réellement prise en charge. Exercez l’état modifié sur une révision identifiable dans zerocode, le tableau de bord web, l’application de bureau, une CLI ou un TUI interactif, un programme d’installation, ou toute autre surface concernée. Utilisez des dimensions représentatives de terminal ou de fenêtre d’affichage, et joignez une ou plusieurs captures d’écran respectueuses de la vie privée montrant le contenu modifié avec suffisamment de mise en page environnante pour en juger le résultat. Ne consignez les dimensions numériques que lorsqu’elles sont nécessaires pour reproduire ou évaluer un problème concret de présentation, tel que le retour à la ligne, le rognage ou la mise en page adaptative.
Le texte rendu à lui seul ne constitue pas automatiquement un changement de présentation visuelle. Un changement d’interface rendu purement sémantique peut s’appuyer sur des preuves automatisées exactes, sur le head exact, issues de la sortie finale de l’interface prise en charge, au lieu d’une capture d’écran, lorsqu’il ne peut affecter ni la mise en page, ni le style, ni le rognage, ni le retour à la ligne, ni le focus, ni la sélection, ni le comportement d’interaction. Les preuves doivent exercer l’interface réelle via son moteur de rendu final, observer la sortie que reçoivent les utilisateurs, et identifier l’état modifié ainsi que le résultat observé. L’inspection du code source, la composition avant rendu, les instantanés limités à un composant et les assertions au niveau des helpers ne sont pas admissibles. Une préoccupation concrète relative à la présentation rétablit l’exigence de capture d’écran de l’interface réelle décrite ci-dessus. Un changement dans un CLI en texte brut, non interactif, sans style et déterministe, dans stdout, stderr ou un journal, peut utiliser la sortie exacte de l’interface prise en charge lorsqu’il ne formule aucune affirmation sensible à la présentation et qu’aucun relecteur n’a identifié de préoccupation concrète à ce sujet. Consigner le contexte pertinent de mise en forme de la sortie, tel que la locale et la largeur du terminal.
Une capture d’écran générée par automatisation est acceptable lorsqu’elle affiche l’interface de production à la frontière revendiquée. Pour les preuves de rendu sémantiques sans capture d’écran, la vérification automatisée doit observer la sortie finale de l’interface prise en charge, par exemple un résultat de navigateur rendu tenant compte de la visibilité ou la sortie finale en cellules de terminal produite par le moteur de rendu TUI réel. Les assertions sur des chaînes, la composition avant rendu, les snapshots de composants seuls et les tests du moteur de rendu au niveau des helpers restent utiles comme preuves de non-régression, mais ne remplacent pas cette frontière. Une capture d’écran ne prouve que l’état visible ; les affirmations d’interaction et de transition nécessitent aussi l’action de l’utilisateur et le résultat observé.
Réutiliser les preuves après une actualisation
Les preuves existantes sous forme de captures d’écran de l’interface réelle n’ont pas besoin d’être recréées uniquement parce qu’une branche a été fusionnée ou rebasée, ou que ses métadonnées ou le corps de sa PR ont changé. Vérifiez le diff intermédiaire par rapport aux états capturés. Réutilisez les preuves lorsque ce diff préserve le comportement de l’interface rendue ainsi que ses entrées sensibles à la présentation ; conservez un moyen d’identifier la révision capturée. Refaites les preuves concernées lorsque le rendu, la mise en page, le retour à la ligne, le rognage, les zones de détection, le texte localisé, le focus, l’interaction, le comportement responsive ou une autre entrée sensible à la présentation changent. Une préoccupation concrète d’un relecteur concernant la présentation exige toujours des preuves pour cette préoccupation.
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 preuves de validation doivent indiquer la révision testée, l’action de l’utilisateur, l’environnement, le résultat attendu et le résultat observé. Pour les modifications visuelles sensibles à la présentation, incluez ou liez les captures d’écran requises, prises à des dimensions de terminal ou de fenêtre d’affichage représentatives, avec suffisamment de contexte environnant pour juger du résultat. N’enregistrez les dimensions numériques que lorsqu’elles sont nécessaires pour reproduire ou évaluer un problème de présentation concret. Pour une modification qualifiante de l’interface rendue, uniquement sémantique, indiquez le HEAD exact, la sortie finale de l’interface prise en charge qui a été exercée, l’état modifié et le contenu visible observé. Pour une modification qualifiante en texte brut déterministe, incluez à la place la sortie exacte de l’interface prise en charge, la révision testée et le contexte pertinent de mise en forme de la sortie. Liez la vérification automatisée ou incluez la commande exacte et sûre lorsque cela aide un autre relecteur à la reproduire. Les captures d’écran prouvent l’état visible, pas le comportement caché ; les journaux ne prouvent que le chemin et le résultat qu’ils consignent.
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.