I'm using partcover to produce codecoverage for a bunch of mstest powered unit tests.
I use the command line:
PartCover.exe --target "c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\MSTest.exe" --target-args "/testcontainer:c:\CrusieControlProjects\AcademyPro\AcademyTests\bin\Release\AcademyTests.dll" --include [AcademyPro*]*
This runs, all tests pass, but I end up with the output:
Results file: C:\Program Files\Gubka Bob\PartCover .NET 2.3\TestResults\Administrator_PSLV22 2009-03-31 17_54_18.trx
Run Configuration: Default Run Configuration
Target PageFaultCount: 10565
Target PagefileUsage: 27631616
Target PeakPagefileUsage: 31297536
Target PeakWorkingSetSize: 31498240
Target QuotaNonPagedPoolUsage: 8180
Target QuotaPagedPoolUsage: 217124
Target QuotaPeakNonPagedPoolUsage: 13012
Target QuotaPeakPagedPoolUsage: 255524
Target WorkingSetSize: 30310400
request target shutdown
<PartCoverReport date="2009-03-31T18:00:36.7676250+01:00" />
When I run with the --output command the xml file ends up with just
<PartCoverReport date="2009-03-31T18:00:36.7676250+01:00" />
Why might this be happening?
To fix this I ended up downgrading.
I was using version 2.3 (which is a dev build) and switched to version 2.2.
Now the tests run fine and I get sensible coverage data.
Maybe that will help someone.
I was having a similar problem with NUnit on x64. The problem was that I was using nunit-console.exe (AnyCPU). Switching to nunit-console-x86.exe (explicitly 32-bit) solved the problem.
I don't have access to an environment with MSTest, but if the executable you're referencing is AnyCPU, you might look for an explicitly 32-bit version of it on your system. Worst case, you could create one using CorFlags.
Related
When I try to execute NUnit test in VSTS task I am getting the following error:
Warning: The path 'C:\a\1\s\INCASOL.IP\packages' specified in the 'TestAdapterPath' does not contain any test adapters, provide a valid path and try again.
I have these tasks in VSTS:
The "Run unit test" task is configured as follows:
Note I have set the "Path to Custom Test Adapters".
I think the dlls for NUnit are properly copied to packages folder because in "Nuget restore" task I can see the following:
Added package 'NUnit.2.6.4' to folder 'C:\a\1\s\INCASOL.IP\packages'
Notes: The NUnit version is 2.6.4 and I'm using Hosted Agent
After a few hours looking for a solution, I solved it few minutes after having asked my question.
Although I could run my test in my local machine using NUnit Test Adapter, this package hadn't been added to my packages folder. So, once I run
Install-Package NUnitTestAdapter
for my test projects, everything works fine.
I have a problem with the standard MSBuild.exe used on our Team Build server, the standard version used is in
"C:\Windows\Microsoft.NET\Framework\v4.0.30319", version 4.0.30319.18408 or
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319" respectively (same version).
Using this version leads to Fake dlls not being generated in the same way as on our local development machines (i.e. some fake methods are missing on the server), resulting in broken builds (unit tests) on the TFS.
I updated the build definition template to use the MSBuild version located under "C:\Program Files (x86)\MSBuild\12.0\Bin" as it is more recent (version 12.0.30723.0), however, this results in an error MSB1025, System.Threading.Tasks.Dataflow, Version=4.5.9.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a not found.
Update
Further investigation - manually adding the System.Threading.Tasks.Dataflow.dll with the correct version number to the MSBuild directory results in a broken build with
Unsupported ToolsVersion 12.0
Manually setting the ToolVersion in the Microsoft.TeamFoundation.Build.Workflow.Acitvities.MSBuild element to "4.0" results in a broken build with
Cannot set unknown member "Microsoft.TeamFoundation.Build.Workflow.Activities.MSBuild.ToolVersion"
So... no real improvement.
Any ideas how to fix this?
Fakes is sensitive to the Visual Studio version. Try passing /p:VisualStudioVersion=12.0 to MSBuild arguments. Also avoid handling System.* assemblies manually.
I use CMake generated solution for Visual Studio 2010.
In my solution I have several lib projects and one exe project.
For Debug build configuration I use output names like lib1_d.lib, lib2_d.lib etc...
For Release build configuration I use lib1.lib, lib2.lib ...
thanks to CMake I have one extra build configuration I use - RelWithDebugInfo. I use same output names for this build configuration as for Release.
Now here is the problem:
Assuming everything is cleaned.
I hit F5 (run / start debugging) RelWithDebugInfo. All project are built (exe is depending on them) and project runs successfully.
I switch to Release and hit F5 again. All project are built and project runs successfully. (libraries in output directory are overwritten)
I switch back to RelWithDebugInfo and hit F5. VS quickly goes through and gives All outputs are up-to-date. ... Build succeeded. And DOES NOT overwrite lib files in output directory. So application crashes because it uses libraries for other build configuration.
This problem occurs for both ordering Release->RelWithDebugInfo and RelWithDebugInfo->Release
I haven't find a solution, how to add other prefix to RelWithDebugLibraries my SO question
Is there a way, to force Visual Studio 2010 to always overwrite outputs? Preferably by some flag which I can provide from CMake.
The VS build system solves this problem by using different build directories for different configurations. By default, 32-bit Debug output goes to the Debug directory, Release output goes to the Release directory, 64-bit Debug output goes to x64\Debug directory, etcetera. This way different configurations never step on each other's output files.
Looks to me like the mistake you made with your added RelwithDebugInfo configuration is that you didn't modify the output file names. So the build system sees an up-to-date output file from another configuration and doesn't think it necessary to rebuild them.
Coming up with variations of build output file names does get to be impractical once you go past two, do consider the VS-way to do this.
I did quite a lot of research on the web and tried a few settings, but I couldn't reproduce the behavior of running MsTest in Visual Studio 2012 on the command line.
Our solution consists of many projects that build to the same bin folder residing at the solution level (e.g. C:\MySolution\bin) - this is the code-under-test (CUT). The tests are grouped in a separate project that resides in its own solution and builds in its own bin folder (e.g. C:\MySolution\Tests\bin). There are really a lot of plugins thus we want MsTest to reference the CUT bin folder when running the test intead of copying everything to the TestResults folder. We did achieve this in Visual Studio 2012 by editing the .testrunconfig and specifying ".\bin" as "root folder for the assemblies to be loaded" (in tab "Unit Test" when editing the testrunconfig). So we can load the test solution in VS2012 and run the tests there without having to copy the bin folder contents to the TestResults directory.
Now I wanted to create a .bat file that would run MsTest the same way as in VS2012 so that we can omit launching Visual Studio just for running the tests. I'm now working on how to execute MsTest on the command line, but have been quite frustrated. This is what I tried (command executed on the solution level in a VS command prompt):
MsTest /testcontainer:Tests\bin\Tests.dll
This did not work at all, it couldn't even find the referenced dlls that Tests.dll need to run. So I re-used the configuration and ran it again:
MsTest /runconfig:LocalTestRun.testrunconfig /testcontainer:Tests\bin\Tests.dll
Still it did not work. It could start the tests, but all of them failed. I got a lot of warnings of the kind
Warning: Test Run deployment issue: The assembly or module '....' directly or indirectly referenced by the test container 'C:\MySolution\Tests\bin\tests.dll' was not found.
and in the end it said:
The configured application base directory 'C:\MySolution\TestResults\User_Machine 2013-07-28 13_16_59\Out\bin' does not exist. The test directory will be used instead.
When I changed the option applicationBaseDirectory in the testrunconfig to an absolute path (C:\MySolution\bin), it worked. Still I get many warnings such as:
Warning: Test Run deployment issue: The assembly or module '....' directly or indirectly referenced by the test container 'C:\MySolution\Tests\bin\tests.dll' was not found.
But anyway, it's not really a feasible solution to specify an absolute path. How can I run MsTest on the command line with a different, but relative assembly base directory?
My LocalTestRun.testrunconfig is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<TestSettings name="Local Test Run" id="...." xmlns="http://microsoft.com/schemas/VisualStudio/TeamTest/2010">
<Description>This is a default test run configuration for a local test run.</Description>
<Deployment>
<DeploymentItem filename="Tests\....\Resources\" />
</Deployment>
<Execution hostProcessPlatform="MSIL">
<TestTypeSpecific>
<UnitTestRunConfig testTypeId="....">
<AssemblyResolution applicationBaseDirectory=".\bin">
<TestDirectory useLoadContext="true" />
</AssemblyResolution>
</UnitTestRunConfig>
<WebTestRunConfiguration testTypeId="....">
<Browser name="Internet Explorer 7.0">
<Headers>
<Header name="User-Agent" value="Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)" />
<Header name="Accept" value="*/*" />
<Header name="Accept-Language" value="{{$IEAcceptLanguage}}" />
<Header name="Accept-Encoding" value="GZIP" />
</Headers>
</Browser>
</WebTestRunConfiguration>
</TestTypeSpecific>
<AgentRule name="LocalMachineDefaultRole">
</AgentRule>
</Execution>
</TestSettings>
After more searching we changed to use the test console runner that is included with VS2012:
VSTest.Console.exe Tests\bin\Tests.dll /Framework:framework40 /Settings:LocalTestRun.testrunconfig
This works with a relative path as applicationBaseDirectory.
This is due to an MSTest bug that sets the current directory to its own working directory, rather than the test project's bin (or deployment) folder. The workaround is to execute the following code in the constructor of your test class:
Environment.CurrentDirectory(AppDomain.CurrentDomain.BaseDirectory);
I got the idea from http://www.ademiller.com/blogs/tech/2008/01/gotchas-mstest-appdomain-changes-in-vs-2008/; however, note that, in my case at least, it required setting Environment.CurrentDirectory, rather than the reverse, as suggested in the article.
I have configured Visual Studio 2010 to debug xUnit.net tests by setting the Project Settings | Debug | Start External Program to run the xUnit.net console runner.
This works OK but only when providing the complete path to the test project dll via the Command Line Arguments eg: "c:\development\TestProject.dll"
I have tried using $(BinDir)$(TargetName)$(TargetExt) as parameters via the Command Line Arguements section but it does not work. Any suggests on how I can avoid the explicit/full path?
This is what I use in my .csproj file to run the xUnit GUI runner as the start action:
<PropertyGroup>
<StartAction>Program</StartAction>
<StartProgram>$(MSBuildProjectDirectory)\..\..\Packages\xunit.runners.1.9.1\tools\xunit.gui.clr4.exe</StartProgram>
<StartArguments>"$(MSBuildProjectDirectory)\$(OutPutPath)$(AssemblyName).dll"</StartArguments>
</PropertyGroup>
For this to work, all you have to do is install the xUnit.net Runners NuGet package:
PM> Install-Package xunit.runners
The only downside so far, is that it's version specific, so every time you update the NuGet package to latest, you should update this configuration to point to the correct runner.
This answer was given before James' and Brad's awesome work with xUnit.net Runners. See michielvoo's answer below.
To avoid the problem of explicitly giving the library name one can use cmd.exe with command line arguements: /C xunit.console.exe $(BinDir)$(TargetName)$(TargetExt)
Check Use Output Window
Use the Tools|Options|Keyboard configuration to assign a hot key.
A alternative route is use a VS plugin as testrunner. For instance ReSharper.
I simply type the full name of the assembly thats all.
Under command line arguments: SharedDataBridge.Tests.dll