À l'exclusion des tests de build tfs

Je veux exclure certains tests à partir de ma version d'intégration continue, mais je n'ai pas trouvé un moyen de le faire.

Une des choses que j'ai essayé était de mettre en place la priorité de ces tests à -2 et puis sur la version que j'ai précisé Minimum Priorité de Test = -1, mais il reste d'exécuter ces tests.

Toute aide serait grandement appréciée.

Qu'est-ce que votre Testeur? MSTest, NUnit, quelque chose d'autre (?)

OriginalL'auteur Yag | 2012-02-20

9

Au lieu d'utiliser le "Test de Listes" qui ont été décrites, vous devez utiliser le "Test de la Catégorie" méthode. Le test des listes & VSMDI fonctionnalités ont été effectivement obsolète dans Visual Studio 2010 et Microsoft peut retirer complètement cette fonctionnalité dans une prochaine version de Visual Studio.

Si vous souhaitez plus d'informations sur la façon d'utiliser le test des catégories en particulier avec votre processus de génération automatique, consultez cet article de blog: http://www.edsquared.com/2009/09/25/Test+Categories+And+Running+A+Subset+Of+Tests+In+Team+Foundation+Server+2010.aspx

Vous pouvez également exclure des catégories test de course en spécifiant le ! (point d'exclamation) devant le nom de la catégorie pour mieux définir votre filtre.

Sur mon implant construction, je suis en cours d'exécution avec "!Intégration&!Charge"

OriginalL'auteur Ed Blankenship
3

Si vous utilisez MSTest vous pouvez créer un Liste De Test pour les tests que vous avez besoin dans vous de l'intégration continue.

Je ne connaissais pas cette fonctionnalité. Il ouvre un nouveau monde de possibilités. Merci!
pour un samle construire config sur comment faire cela avec TFS 2008 équipe se construit, voir mon post ci-dessous. Pour TFS 2010, la définition de build est basé sur les processus, mais le principe est le même.
Bon à savoir: le "Test de la Liste" approche (à l'aide .VSMDI) des fichiers a été abandonné et n'est pas suggéré pour les utiliser plus longtemps. Au lieu de cela, vous devez utiliser le Test de Catégories pour MSTest. Microsoft peut complètement supprimer de la liste de tests de fonctionnalité dans une prochaine version de Visual Studio. - Je avoir plus d'information, cliquer ici si vous êtes intéressés: edsquared.com/2009/09/25/...

OriginalL'auteur Huusom

Avec MSTest, vous pouvez simplement créer deux projets de test (sous-ensembles) et de spécifier un seul dans la construction de config à utiliser pour le test. Dans MSBuild, c'était la voie à suivre. Pour la nouvelle WF-en Fonction des définitions de build, j'ai actuellement n'ont pas un échantillon à la main:

<ItemGroup>
    <!--  TEST ARGUMENTS
     If the RunTest property is set to true then the following test arguments will be used to run 
     tests. Tests can be run by specifying one or more test lists and/or one or more test containers.

     To run tests using test lists, add MetaDataFile items and associated TestLists here.  Paths can 
     be server paths or local paths, but server paths relative to the location of this file are highly 
     recommended:

        <MetaDataFile Include="$(BuildProjectFolderPath)/HelloWorld/HelloWorld.vsmdi">
            <TestList>BVT1;BVT2</TestList>
        </MetaDataFile>

     To run tests using test containers, add TestContainer items here:

        <TestContainer Include="$(OutDir)\AutomatedBuildTests.dll" />
        <TestContainer Include="$(SolutionRoot)\TestProject\WebTest1.webtest" />
        <TestContainer Include="$(SolutionRoot)\TestProject\LoadTest1.loadtest" />

     Use %2a instead of * and %3f instead of ? to prevent expansion before test assemblies are built
    -->
</ItemGroup>

<PropertyGroup>
    <RunConfigFile>$(SolutionRoot)\LocalTestRun.testrunconfig</RunConfigFile>
</PropertyGroup>

Conseil: Pour utiliser un générique de définition de build, nous nom de tous nos projets de Test "AutomatedBuildTests", c'est à dire il n'y a pas de solution différence. Donc, la définition de build peut être inclus dans une définition de build (ou même d'être une commune) qui s'exécute toujours le bon ensemble de tests. Il serait facile d'ajouter un "s'il existe" afin de permettre une définition de build pour exécuter uniquement les tests quand un montage d'Essai est présent. Nous n'utilisons pas ce afin d'obtenir les erreurs de compilation lorsque aucun test de l'assemblée est trouvé que nous voulons absolument tester avec toutes ces versions qui utilisent cette définition.

OriginalL'auteur eFloh

0

Ma préférence serait comme ci-dessus à l'aide d'une Liste de Test, mais certaines personnes ont émis fusion/modifier le vsmdi fichiers... nous Nous retrouvons avec des solutions distinctes et utiliser un modèle de match pour exécuter tous les tests dans la DLL.

OriginalL'auteur Daniel Morritt
0

Dans Visual Studio 2012 et plus tard, vous pouvez configurer votre définition de build à l'aide de la Test case filter réglage.

Ce paramètre fait partie de votre définition de build.
Ouvrez la définition de build et accédez à la Process onglet. Dans la section 3. Test vous pouvez définir plusieurs sources de test. Pour chaque source de test, vous pouvez spécifier un Test case filter.

Vous pouvez trouver les détails dans cet article MSDN: Course sélective des tests unitaires dans visual studio 2012 RC à l'aide de TestCaseFilter

J'ai copié les opérateurs pris en charge et quelques exemples de cet article:

Opérateurs pris en charge dans les RC sont:

1.= (est égal à)

2.!= (pas égal à)

3.~ (contient ou chaîne uniquement pour les valeurs de chaîne)

4.& (et)

5.| (ou)

6.( ) (paranthesis pour le groupement)

Expresssion peuvent être créés à l'aide de ces opérateurs que pour être valable, toute condition logique. & (et de) a plus
la priorité sur | (ou), tandis que l'évaluation de l'expression.

E. g.

"TestCategory=NAR|Priorité=1"
"Owner=vikram&TestCategory!=L'INTERFACE utilisateur"
"FullyQualifiedName~NameSpace.Class"

"(TestCategory!=UI&(Priorité=1|Priorité=2))|(TestCategory=UI&Priorité=1)"

Une autre possibilité serait d'avoir quelques sources de test dans une définition de build dans certains (c'est à dire plus ou moins) sources de test dans d'autres définitions de build.

OriginalL'auteur Martin

Vous devez vous connecter pour publier un commentaire.