Cette action crée un nouveau plan et des suites après confirmation. D’autres fonctions de TestPulse écrivent aussi dans Azure DevOps : consultez la matrice des actions pour leurs cibles et leurs effets.
TestedBy et laisse les trous vides (échafaudage vivant : le jour où un test est écrit et lié, il apparaît tout seul).
C’est de la création seule : jamais de modification ni de suppression d’un plan, suite ou test existant. Une collision de nom avertit au lieu d’écraser, et un échec partiel rapporte exactement ce qui a été créé.
Choisir l’area path (et l’itération)
Avant de créer, choisissez l’area path (et en option l’itération) sous lequel le nouveau plan vivra. Laissez les deux vides et le plan est créé sous la racine du projet. Les listes viennent des classification nodes du projet via le scopevso.work existant — aucune nouvelle permission — et vous pouvez toujours saisir un chemin à la main.
Le 403 « permission ≠ scope »
L’échec de création le plus courant est un 403 — vous n’avez pas les permissions appropriées pour gérer les plans de test sous cet area path.Lorsque le message précise que vous ne pouvez pas gérer les plans sous cette area path, vérifiez cette permission. Le code 403 seul ne suffit pas à conclure ; vérifiez aussi l’approbation des permissions de l’extension.
La permission d’écriture
La création utilise le scopevso.test_write, déjà déclaré dans le manifeste TestPulse. Lorsqu’une mise à jour ajoute un scope, un administrateur de l’organisation approuve les nouvelles permissions de l’extension ; il n’a pas à modifier le manifeste. Tant qu’il n’est pas accordé, l’analyse en lecture seule et l’export fonctionnent pleinement — seule la création est indisponible.
À suivre
Coverage Builder — vue d'ensemble
Analyser et exporter d’abord.
Lecture seule par conception
Lectures, sauvegardes et écritures.