C# 使用 VSTest 代替 MSTest 运行单元测试用例

Using VSTest to run unit test cases instead of MSTest

提问by Arkanoid

I have an x64 platform C# solution(VS2012) on a TFS2010 server. I have attached a unit test project (also x64) to this solution and created a build definition. When I queue the build, it succeeds but the unit test cases will not be executed. This is because MSTest is a 32 bit application. So, I decided to customize the default build process template (DefaultTemplate.xaml) to invoke VSTest(VSTest.console.exe) instead of MSTest. This is quite complex and I am unable to add a build activity to the toolbox for VSTest.

我在 TFS2010 服务器上有一个 x64 平台 C# 解决方案（VS2012）。我已将单元测试项目（也是 x64）附加到此解决方案并创建了构建定义。当我排队构建时，它成功但不会执行单元测试用例。这是因为 MSTest 是一个 32 位应用程序。因此，我决定自定义默认构建过程模板 (DefaultTemplate.xaml) 以调用 VSTest(VSTest.console.exe) 而不是 MSTest。这非常复杂，我无法将构建活动添加到 VSTest 的工具箱中。

Has anyone done this kind of customization? I have also considered other approaches like configuring .runsettings file. Do we have a VSTest adapter interface that can be added in the .runsettings file ?

有没有人做过这种定制？我还考虑了其​​他方法，例如配置 .runsettings 文件。我们是否有可以添加到 .runsettings 文件中的 VSTest 适配器接口？

采纳答案by Arkanoid

Executing unit tests through VSTest and publishing the test results through MSTest gave me a successful outcome. Given below is the Powershell script:

通过 VSTest 执行单元测试并通过 MSTest 发布测试结果给了我一个成功的结果。下面给出的是 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

回答by Wilbert

This does not directly answer you question, but it might help. I did a similar thing for TeamCity. I used command-line to call vstest.console.exe and created a .runsettings file.

这不会直接回答您的问题，但可能会有所帮助。我为 TeamCity 做了类似的事情。我使用命令行调用 vstest.console.exe 并创建了一个 .runsettings 文件。

I used this Microsoft templatefor the runsettings file. Note however that on my machine, the path mentioned in the comment in Line 5 is relative to the .runsettings location, not the .sln.

我将这个Microsoft 模板用于 runsettings 文件。但是请注意，在我的机器上，第 5 行注释中提到的路径是相对于 .runsettings 位置的，而不是 .sln。

If you use /logger:trx option of vstest.console.exe, it will generate output in the same format as MSTest (good for result visualization).

如果使用 vstest.console.exe 的 /logger:trx 选项，它将生成与 MSTest 格式相同的输出（有利于结果可视化）。

回答by Kosta Tenedios

I too have the exact same need for using VSTest.Console.exe instead of MSTest.exe for a TFS2010 build process that compiles a VS2012/.NET 4.5 x64 application, while waiting for the upgrade to TFS2012 to commence.

对于编译 VS2012/.NET 4.5 x64 应用程序的 TFS2010 构建过程，我也同样需要使用 VSTest.Console.exe 而不是 MSTest.exe，同时等待升级到 TFS2012 开始。

The approach I have taken was to edit the build script XAML, deleted the existing workflow for unit tests and replaced it with a customised workflow that builds up the VSTest.Console.exe parameters and then executes VSTest.Console.exe via InvokeProcess. I then ensured that in the Finally block that regardless of test result that we publish the test results and code coverage to TFS using MSTest.exe from a VS2012 installation on the build server.

我采用的方法是编辑构建脚本 XAML，删除现有的单元测试工作流，并用自定义工作流替换它，该工作流构建 VSTest.Console.exe 参数，然后通过 InvokeProcess 执行 VSTest.Console.exe。然后我确保在 finally 块中，无论测试结果如何，我们都使用构建服务器上的 VS2012 安装中的 MSTest.exe 将测试结果和代码覆盖率发布到 TFS。

Unfortunately I cannot post the XAML in the answer as it exceeds character length, but I do have a text file consisting of the snippet to be replaced in DefaultTemplate.xaml and what to replace it with. The file can be found here. Please note that although this approach works it is a hack.

不幸的是，我无法在答案中发布 XAML，因为它超过了字符长度，但我确实有一个文本文件，其中包含要在 DefaultTemplate.xaml 中替换的代码段以及替换内容。该文件可以在这里找到。请注意，虽然这种方法有效，但它是一个黑客。

Another alternative would be to use NUnit instead of MSTest or VSTest.Console as this support 64-bit binaries. This articleexplains how to integrate NUnit in a TFS2010 build script, and has links to tools and resources required to make this happen. The only issues with NUnit are code coverage (need yet another tool plus work out how to publish these results to TFS) and MSTest-style integration tests using attributes such as DeploymentItem and properties such as TestContext, which is why where I work we opted with the VSTest.Console.exe approach.

另一种选择是使用 NUnit 而不是 MSTest 或 VSTest.Console，因为它支持 64 位二进制文​​件。该文章介绍了如何NUnit的在TFS2010构建脚本集成，并具有指向工具和资源来实现这一目标需要。NUnit 的唯一问题是代码覆盖率（需要另一个工具以及如何将这些结果发布到 TFS）和 MSTest 风格的集成测试，这些测试使用诸如 DeploymentItem 之类的属性和诸如 TestContext 之类的属性，这就是我们选择使用的原因VSTest.Console.exe 方法。

And from what I have read TFS2012 offers easy integration to VSTest.Console.exe from build scripts, so if you do ever upgrade to TFS2012 the VSTest.Console.exe hack that I have documented may not be required.

从我读过的内容来看，TFS2012 提供了从构建脚本到 VSTest.Console.exe 的轻松集成，因此，如果您确实升级到 TFS2012，则可能不需要我记录的 VSTest.Console.exe hack。