web-dev-qa-db-fra.com

Utilisation de VSTest pour exécuter des cas de test unitaires au lieu de MSTest

J'ai une solution de plate-forme x64 C # (VS2012) sur un serveur TFS2010. J'ai joint un projet de test unitaire (également x64) à cette solution et créé une définition de construction. Lorsque je mets en file d'attente la construction, l'opération réussit, mais les cas de test unitaires ne seront pas exécutés. En effet, MSTest est une application 32 bits. J'ai donc décidé de personnaliser le modèle de processus de génération par défaut (DefaultTemplate.xaml) pour appeler VSTest (VSTest.console.exe) au lieu de MSTest. C'est assez complexe et je ne peux pas ajouter d'activité de construction à la boîte à outils de VSTest.

Quelqu'un at-il fait ce genre de personnalisation? J'ai également envisagé d'autres approches telles que la configuration du fichier .runsettings. Avons-nous une interface d'adaptateur VSTest qui peut être ajoutée dans le fichier .runsettings?

c#xamltfsvisual-studio-2012build-process
12
Arkanoid

L'exécution de tests unitaires via VSTest et la publication des résultats de test via MSTest m'ont permis d'obtenir un résultat positif. Ci-dessous, le script Powershell:

#  Get the UnitTest Binaries
$files = Get-ChildItem $TestAssembliesDir\*est*.dll

#  VSTest.console.exe path
$VSTestPath = 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe'

#  MSTest path
$MSTestpath = "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\mstest.exe"
#  Loop through the test assemblies and add them to the VSTestFiles

$VSTestFiles = ''  
foreach($file in $files)  
{   
    $VSTestFiles += "`"$file`"" 
    $VSTestFiles += " "
} 

#  Run the UnitTests using VSTest 
&$VSTestPath  $vstestplatform "/Framework:Framework45" "/InIsolation" $VSTestFiles "/logger:trx"

#  Get TRX files
$TrxFilesList = Get-ChildItem $TestResDir\*.trx
$TrxFiles = ''  
$loop = 1
foreach($file in $TrxFilesList)  
{   
    $TrxFiles = "$file" 
    # copy the trx file into a space-less named trx
    $newTrxFileName = "$BuildUri" + "_" + "$loop" + ".trx"

    copy-item $TrxFiles -destination $TestResDir\$newTrxFileName

    $loop = $loop + 1
    $newTrxFile += "$TestResDir\$newTrxFileName"
    $newTrxFile += " "
} 

#  specify MSTest arguments 
$mspubl = "/publish:"+$TeamProjColUri
$msteampr = "/teamproject:" + $TeamProj
$mspublbuild = "/publishbuild:" +$BuildUri
$mspubresfile = "/publishresultsfile:" +"`"$newTrxFile`""
#Publish test results through MSTest
&$MSTestpath  $mstestplatform $flavor $mspubl $msteampr $mspublbuild $mspubresfile
17
Arkanoid

Moi aussi, j'ai exactement le même besoin d'utiliser VSTest.Console.exe au lieu de MSTest.exe pour un processus de génération TFS2010 qui compile une application VS2012/.NET 4.5 x64, en attendant le début de la mise à niveau vers TFS2012.

L'approche que j'ai adoptée consistait à modifier le script de génération XAML, à supprimer le flux de travail existant pour les tests unitaires et à le remplacer par un flux de travail personnalisé qui construit les paramètres VSTest.Console.exe, puis exécute VSTest.Console.exe via InvokeProcess. Je me suis ensuite assuré que, dans le bloc Finally, quel que soit le résultat du test, nous publions les résultats du test et la couverture de code dans TFS à l'aide de MSTest.exe à partir d'une installation VS2012 sur le serveur de génération.

Malheureusement, je ne peux pas poster le XAML dans la réponse car il dépasse la longueur des caractères, mais j'ai un fichier texte contenant l'extrait de code à remplacer dans DefaultTemplate.xaml et les éléments à remplacer par celui-ci. Le fichier peut être trouvé ici . S'il vous plaît noter que bien que cette approche fonctionne, c'est un hack.

Une autre solution consisterait à utiliser NUnit au lieu de MSTest ou VSTest.Console car cela prend en charge les fichiers binaires 64 bits. Cet article explique comment intégrer NUnit dans un script de génération TFS2010 et propose des liens vers les outils et les ressources nécessaires pour que cela se produise. Les seuls problèmes avec NUnit sont la couverture de code (un outil supplémentaire est nécessaire, ainsi que la publication de ces résultats dans TFS) et les tests d'intégration de type MSTest utilisant des attributs tels que DeploymentItem et des propriétés telles que TestContext. C'est pourquoi nous avons opté pour cette solution. l'approche VSTest.Console.exe.

Et d'après ce que j'ai lu, TFS2012 offre une intégration facile à VSTest.Console.exe à partir de scripts de génération. Par conséquent, si vous effectuez une mise à niveau vers TFS2012, le piratage VSTest.Console.exe que j'ai documenté peut ne pas être requis.

4
Kosta Tenedios

Cela ne répond pas directement à votre question, mais cela pourrait aider. J'ai fait la même chose pour TeamCity. J'ai utilisé la ligne de commande pour appeler vstest.console.exe et créer un fichier .runsettings.

J'ai utilisé ce modèle Microsoft pour le fichier runsettings. Notez cependant que sur ma machine, le chemin mentionné dans le commentaire de la ligne 5 est relatif à l'emplacement .runsettings, pas à celui-ci.

Si vous utilisez l'option/logger: trx de vstest.console.exe, il générera une sortie au même format que MSTest (utile pour la visualisation des résultats).

0
Wilbert