Hiérarchie des catégories de test de Visual Studio 2012 (Test Explorer)

Question

Je teste un projet assez important (C#, VS2012), et j'ai besoin d'organiser mes tests unitaires dans une hiérarchie de tests (par exemple, j'ai maintenant 43 cas de test). J'ai vraiment besoin de cette hiérarchie.

J'ai déjà défini des catégories de tests et l'explorateur de tests affiche les cas de test par caractéristiques. J'ai défini les catégories de cette manière (un test peut avoir plusieurs catégories)

• TestCase01 : MainTestType, SubTestType, SubsubTestType
• ...
• TestCase10 : MainTestType, SubTestType, SubsubTestType
• TestCase11 : MainTestType, SubTestType2, SubsubTestType2
• ...
• TestCase15 : MainTestType, SubTestType2, SubsubTestType2

Défini comme suit :

    [TestMethod]
    [TestCategory("MainTestType")]
    [TestCategory("SubTestType")]
    [TestCategory("SubsubTestType")]
    public void MyTestCase()
    { /* etc. */

Mais Test Explorer montre le suivant :

• MainTestType : tous les tests ayant la catégorie MainTestType
• SubTestType : tous les tests ayant la catégorie SubTestType
• etc...

La hiérarchie me manque donc vraiment. J'ai essayé "Cat1 \Cat2\Cat3 "Mais aucune hiérarchie ne s'affiche. Savez-vous comment faire, ou un addon gratuit qui peut le faire pour moi ?

J'aurai également besoin de ce type de catégorisation, car nous exécutons souvent des tests à partir de la ligne de commande, et mstest.exe peut exécuter des tests pour une catégorie (par exemple tous les MainTestType, ou SubTestType). (Je m'en tiens à mstest car la moitié de l'équipe utilise vs2010). Mais la solution est suffisante pour vs2012.

Je vous remercie d'avance.

Answer 1

Comme ce que j'ai cherché n'est pas pris en charge pour l'instant, j'ai trouvé la solution suivante :

• construire le projet
• exécuter MSText pour tous les tests -> sortie .trx
• programme winforms/wpf simple, qui analyse le fichier .trx, récupère les cas de test et les affiche dans une arborescence
• Maintenant nous pouvons exécuter mstest à partir de cette application pour le noeud sélectionné -> crée une sortie .trx (qui peut être ouverte dans VS)

J'ai utilisé .trx parce que de cette façon je n'ai pas à analyser l'assemblage, mstest.exe le fait. Les catégories de test sont créées de cette manière :

[TestCategory("MainTestType")]
[TestCategory("MainTestType/SubTestType")]
[TestCategory("MainTestType/SubTestType/SubsubTestType")]

Voici donc la solution de contournement qui est simple, un seul binaire et que les développeurs peuvent également utiliser. Le problème avec les listes de lecture est qu'elles ne sont pas non plus hiérarchisées.

Answer 2

Test Explorer n'affiche que les groupes qui suivent le schéma TestFilter/InnerTests.

L'onglet de l'explorateur de nouveaux tests est un conteneur générique. En utilisant des adaptateurs/addon/plugin spécifiques, vous pouvez intégrer d'autres frameworks de test (NUnit, xUnit, Qunit, ...) dans Test Explorer ... mais ces adaptateurs doivent suivre l'interface de l'explorateur de test.

Il n'est donc pas supporté nativement par l'onglet de l'explorateur de tests, je n'ai pas trouvé dans le passé de moyen d'étendre l'onglet de l'explorateur de tests.

Peut-être qu'un autre cadre de test vous permettra d'avoir une hiérarchie, mais ce sera dans un autre onglet personnalisé et avec un autre attribut (TestCategory est un attribut MSTest).

À titre d'information, vous pouvez également combiner des traits dans la fenêtre de l'explorateur de tests de la manière suivante

Trait:"MainTestType1"  Trait:"SubTestType3"

Answer 3

Pour le regroupement dans VS2010, utilisez .vsmdi qui pourraient être ouverts dans Test List Editor .

En ce qui concerne VS2012 :

Visual Studio 2012 Update 1 http://www.microsoft.com/visualstudio/eng/visual-studio-update a été amélioré pour permettre le regroupement et le filtrage par projet et par caractéristiques (catégorie). L'utilisation de ces fonctionnalités est détaillée dans cet article de blog, http://blogs.msdn.com/b/visualstudioalm/archive/2012/11/09/how-to-manage-unit-tests-in-visual-studio-2012-update-1-part-1-using-traits-in-the-unit-test-explorer.aspx

Le regroupement et le filtrage par classe sont terminés et seront disponibles dans la mise à jour 2.

Je vous suggère de déplacer vos catégories dans l'espace de noms, afin que vous puissiez voir la hiérarchie plate dans la fenêtre TestView dans la colonne FullClassName.

Answer 4

Vous pourriez tricher un peu en faisant de votre trait de niveau 2 une concaténation des valeurs de vos deux premiers niveaux. Ainsi, si le niveau 1 est Animal et le niveau 2 Mammifère, vous pourriez avoir un trait "Animal.Mammifère". Dans l'explorateur de tests, vous obtiendrez un nœud pour Level1 [Animal] , un autre pour Level1 [Plant] et ensuite un pour Level2 [Animal.Tiger] . Je crois que le filtre prend en charge les correspondances de sous-chaînes, c'est donc une façon de les trier. Vous n'obtenez toujours pas de vue arborescente (bien que si vous étiez déterminé à le faire, vous pourriez essayer d'étendre les caractères ascii art pipe comme l'ancienne commande DOS tree).

Le problème demeure également que l'on ne peut pas fusionner des caractéristiques différentes (de sorte que tous les oiseaux se retrouveraient ensemble dans la liste jusqu'au bas de l'échelle).

D'autre part, il serait délicat d'imposer une structure hiérarchique tout en autorisant des n-tuples de traits. Il faudrait limiter les éléments à plus d'un chemin à partir du sommet de la hiérarchie, détecter et signaler les cycles, utiliser un contrôle d'arbre au-dessus (ou matriciel) de ce qui existe actuellement. De plus, lorsque vous remaniez le code et que vous souhaitez que les tests soient organisés en parallèle, une trop grande structure existante pourrait causer des maux de tête.