J'ai remarqué qu'il y a un attribut Microsoft.visualstudio.testtools.Unittesting.workItematTresting.workItemattribute disponible dans Visual Studio Test (j'utilise VS 2010 Premium et Travailler avec TFS 2010.)
Marquage d'une méthode de test avec un numéro d'article de travail Cela semble pratique, mais cela fait-il vraiment quelque chose? Je ne peux pas dire s'il y a un support d'outil pour elle du tout. J'ai défini un haut comme ceci: mais pas de magie - je pensais que le menu contextuel de l'essai dans la fenêtre des résultats de test pourrait peut-être ouvrir l'élément de travail ou l'équipe. L'explorateur peut avoir une fonctionnalité pour rechercher des tests. Documentation MSDN n'est pas une aide non plus. Quel est cet attribut bon pour?
6 Réponses :
Il est de relier le test de l'unité à un élément de travail dans TFS. Je fournirais un lien à plus d'informations, mais il semble que cela soit vraiment mal documenté.
Je ne l'ai pas utilisé moi-même, mais croyez qu'il peut être utilisé pour générer des rapports sur l'état des éléments de travail.
Selon " Test de logiciel avec Visual Studio® 2010 "par Jeff Levinson (Addison-Wesley Professional, Février 2011, ISBN-10: 0-321-73448-3):
Cela signifie également qu'une propriété existante ne doit plus être utilisée: Éléments de travail associés. Cette valeur n'est pas signalée aux données entrepôt et donc ne peut pas être utilisé pour les rapports. Si vous êtes actuellement Utilisez cette propriété, envisagez d'associer votre test avec un test réel Type d'élément de travail de cas.
La réponse est donc, n'utilisez pas cela avec TFS 2010.
L'attribut de méthode de test WORKITEM n'est pas utilisé pour associer des méthodes de test pour tester les cas. Il est généralement utilisé pour associer une méthode de test avec un bug.
Exemple C # associé de index de code - Comment découvrir des tests ignorés : Lorsque vous utilisez Mstest pour construire votre suite de tests unitaires, vous pouvez utiliser le
attribut [ignorer] pour dire au moteur Mstest de ne pas exécuter un test à la place
de la commenter. Vous pouvez également utiliser l'attribut [Workitem (ID)] pour
Lier le test de l'unité à une base de données de bugs (telle que TFS), de sorte que vous
peut tracer pourquoi un test particulier a été marqué comme ignoré:
Je me souviens vraiment que j'ai utilisé cet attribut avant et les résultats du test ont été attachés au Workitem respectif.
Cependant, avec Visual Studio 2012, cela ne fonctionne plus, ou j'ai oublié quel mécanisme était en réalité responsable de la magie. Pourrait-il être que cela ne fonctionne que via le serveur de construction?
Ce n'est plus nécessaire: dans vs 2013 via Codelens
trouver des éléments de travail liés (ALT + 7)
Recherche de code lié (ALT + 8)
Trouvez des bugs liés (ALT + 9)
Pour examiner la définition d'un test, double-cliquez sur le test.
Oh! Pour ceux qui chérissent Lync:
Contactez le propriétaire d'un élément (Shift + F10)
Les attributs de tirage de l'essai binaire sont vraiment utiles lorsque vous disposez d'un harnais de test cultivé à la maison construit pour exécuter des tests d'unités d'interface utilisateur Selenium.
Après une panne de test, je peux tirer la valeur WorkItemattribute à l'aide de System.Reflection.Memberinfo.Customattributes, puis recherchez l'ID avec l'API TFS. Si l'élément de travail est un bogue et qu'il est toujours actif, je peux résoudre automatiquement l'échec de cette bogue. De cette manière, je peux exécuter le test d'échec tous les jours et résoudre automatiquement l'échec de la réduction de la randomisation.