Ohne tests aus der tfs-build

Anstelle von "Test-Liste", die beschrieben worden sind, sollten Sie die "Test-Kategorie" - Methode. Die test-Listen & VSMDI-Funktionalität haben eigentlich schon veraltet in Visual Studio 2010 und Microsoft können entfernen Sie die Funktion vollständig in einer zukünftigen version von Visual Studio.

Wenn Sie möchten, etwas mehr Informationen darüber, wie die Verwendung von test-Kategorien vor allem mit Ihrem automatisierten build-Prozess, Lesen Sie in diesem blog-post: http://www.edsquared.com/2009/09/25/Test+Categories+And+Running+A+Subset+Of+Tests+In+Team+Foundation+Server+2010.aspx

Können Sie auch ausschließen, test-Kategorien vom laufen durch die Angabe der ! (Ausrufezeichen) - Zeichen vor den Namen der Kategorie, um weiter zu definieren Ihre filter.

Mit MSTest, können Sie einfach erstellen Sie zwei test-Projekte (Baugruppen) und geben Sie nur eine in der build-config für die Prüfung zu verwenden. In MSBuild, war dies der Weg zu gehen. Für das neue WF-Basierte build-Definitionen, die ich derzeit nicht haben, ein Beispiel an die hand:

<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>

Tipp: benutzen Sie eine generische build-definition-nennen wir alle unsere Test-Projekte "AutomatedBuildTests", d.h. es gibt keine Lösung Unterschied. Also die build-definition kann in einer beliebigen existierenden build-definition (oder sogar Häufig), dass führt immer die richtigen tests. Es wäre eine einfache Aufgabe voranstellen einer "if exists" überprüfen, um zu ermöglichen, eine build-definition nur tests ausführen, wenn eine Test-Montage vorhanden ist. Wir sind nicht mit dieser in Reihenfolge zu get build-Fehler, wenn keine test-assembly gefunden, die wir unbedingt testen wollen mit all jene baut, die sich an diese definition.

In Visual Studio 2012 und später können Sie konfigurieren Sie Ihren build-definition mit den Test case filter Einstellung.

Diese Einstellung ist Teil Ihrer build-definition.
Öffnen Sie die build-definition und navigieren Sie zu der Process tab. Im Abschnitt 3. Test Sie können definieren mehrere test-Quellen. Für jeden test Ihre Quelle angeben können Test case filter.

Details finden Sie in diesem MSDN-Artikel: Laufen selektiver unit-tests in VS 2012 RC mit TestCaseFilter

Habe ich kopiert die unterstützten Operatoren und einige Beispiele aus diesem Artikel:

Betreiber unterstützt im RC sind:

1.= (equals)

2.!= (nicht gleich)

3.~ ("enthält" oder " substring-nur für string-Werte)

4.& (und)

5.| (oder)

6.( ) (paranthesis für die Gruppierung)

Expresssion können erstellt werden, mithilfe dieser Operatoren als alle gültigen logischen Zustand. & (und) hat eine höhere
Vorrang vor | (oder) bei der Auswertung Ausdruck.

E. g.

"TestCategory=NAR|Priority=1"
"Owner=vikram&TestCategory!=UI"
"FullyQualifiedName~NameSpace.Class"

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

Andere Möglichkeit wäre, haben einige test-Quellen in einer build-definition, die in einigen (d.h. mehr oder weniger) test-Quellen in anderen build-Definitionen.