Archive

Archive for April, 2011

Multiple Test Runner Scenarios in MSBuild

April 15, 2011 Leave a comment

Scenario:

SubSpec is built for .NET as well as for Silverlight. For the .NET test suite, we use the xUnit MSBuild task to execute the tests, for Silverlight we use a combination of Statlight and xunitContrib. Whenever you run a suite of tests, it’s usually desirable to have a failing test break the build, however under all circumstances the complete suite of tests should be run to give you an accurate feedback.

Our build script looks something like this:
SubSpec.msbuild:

    <Target Name="Test" DependsOnTargets="Build">
		<MSBuild
            Projects="SubSpec.tests.msbuild"
            Properties="Configuration=$(Configuration)" />
    </Target>

SubSpec.tests.msbuild:

  SilverlightTests"/>

  <Target Name="xUnitTests">
    <xunit
      Assemblies="@(TestAssemblies)"/>
  </Target>

  <Target Name="SilverlightTests">
    <Exec
      Command=""tools\StatLight\StatLight.exe" @(SilverlightTestXaps -> '-x="%(Identity)"', ' ') --teamcity" />
  </Target>

Problem:

When using each of the build runners (xUnit MSBuildTask, Statlight) in isolation with multiple assemblies, they do the right thing: Run all tests, fail if at least one test failed, succeed otherwise. Now imagine we have a test succeeding under .NET but failing under Silverlight. When we run xUnit first, we get the desired result. But if Statlight was to run before xUnit, we would never know if the .NET suite would actually succeed, because Statlight stops the build.

(Non-)Solutions:

The first (and most intuitive) idea was to move the test targets into a separate MSBuild project and call MSBuild on that project with ContinueOnError=”false”:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <Target Name="Build">
    <MSBuild
      Projects="test.msbuild"
      Targets="Test"
      ContinueOnError="true"/>
  </Target>

  <Target Name="Test" DependsOnTargets="Foo;Bar">
  </Target>

  <Target Name="Foo">
    <Error Text="Foo"/>
  </Target>

  <Target Name="Bar">
    <Error Text="Bar"/>
  </Target>
</Project>

But this yields only Foo as the error (I wanted to see error: Foo and error: Bar).

MSDN says about ContinueOnError:

Optional attribute. A Boolean attribute that defaults to false if not specified. If ContinueOnError is false and a task fails, the remaining tasks in the Target element are not executed and the entire Target element is considered to have failed.

This is probably why it doesn’t make sense on the MSBuild task, it would only allow another task after the MSBuild task in “Build” to execute. We confirm this by:

  <Target Name="Build">
    <MSBuild
      Projects="test.msbuild"
      Targets="Test"
      ContinueOnError="true"/>
    <Message Text="Some Message"/>
  </Target>
  

And we see Foo as well as Some Message. At this point, it was clear me to me that I want a target that fails if any of its tasks failed, but executes all of them.

In MSDN, we discover StopOnFirstFailure:

true if the task should stop building the remaining projects as soon as any one of them may not work; otherwise, false.

If we specified separate projects, it would work, but we’re in the same project, so unfortunately this won’t help

The next idea was to use CallTarget with ContinueOnError=”true”, like:

  <Target Name="Build">
    <MSBuild
      Projects="test.msbuild"
      Targets="Test"
      ContinueOnError="false"/>
        <Message Text="I should not be executed"/>
  </Target>

  <ItemGroup>
    <TestTargets
        Include="Foo;Bar" />
  </ItemGroup>

  <Target Name="Test">
    <CallTarget Targets="%(TestTargets.Identity)" ContinueOnError="true"/>
  </Target>

  <Target Name="Foo">
    <Error Text="Foo"/>
  </Target>

  <Target Name="Bar">
    <Error Text="Bar"/>
  </Target>
  

However, “I should not be executed” appears in the output log, what happened? Build called MSBuild with ContinueOnError=false (the default). Because all tasks in Test were ContinueOnError=true, no error bubbled up to MSBuild and it executed without error. This is dangerous, because it makes our build appear succeeded when it’s not.

The next option I tried was using RunEachTargetSeparately:

Gets or sets a Boolean value that specifies whether the MSBuild task invokes each target in the list passed to MSBuild one at a time, instead of at the same time. Setting this property to true guarantees that subsequent targets are invoked even if previously invoked targets failed. Otherwise, a build error would stop invocation of all subsequent targets. The default value is false.

  <Target Name="Build">
    <MSBuild
      Projects="test.msbuild"
      Targets="Foo;Bar"
      RunEachTargetSeparately="true"/>
  </Target>

  <Target Name="Test" DependsOnTargets="Foo;Bar">
    <Error Text="Foo"/>
  </Target>

  <Target Name="Foo">
    <Error Text="Foo"/>
  </Target>
  <Target Name="Bar">
    <Error Text="Bar"/>
  </Target>
  

This gives us exactly what we want, but it doesn’t allow test runs to be parallelized. To achieve that, we need to put each test target in a separate project file. It turns out, that using this strategy, we don’t need to worry about controlling our failure strategy: Both projects get build and the MSBuild task reports an error when any of the projects have failed:

  <Target Name="Build">

  </Target>

  <Target Name="Test">
    <MSBuild
      Projects="SubSpec.test.msbuild;SubSpec.Silverlight.test.msbuild"/>
  </Target>
  

Whats the alternative? The Alternative is capturing the ExitCodes of the runners, as described in http://stackoverflow.com/questions/1059230/trapping-error-status-in-msbuild/1059672#1059672, however I don’t like that approach since it’s a bit messy. The only thing we give up by using multiple projects is that it’s harder to get an overview of what happens where, but I think in this case the separation might also aid a proper separation of concerns.

Categories: .NET, MSBuild, Testing, Tools

Running MSTest 9 on a CI Server without installing Visual Studio

April 2, 2011 3 comments

Disclaimer: I would have loved to migrate to a different framework (and I would strongly advice you do so if you’re not a full stack TeamSystem shop), however I have a couple of consultants on that project who are not very test experienced and having built-in MSTest has compelling advantages. Having said that, I know that Gallio has nice VS integration that you can use to run any frameworks’ tests inside Visual Studios Test windows, however that would require each developer to install gallio on their machine (which is bad too).

Without reiterating the tirades of hate Microsoft has earned for making it impossible to run MSTest on a build server without installing Visual Studio, I want to present what I have compiled from several sources to get it working for me:

  1. See this post on Stackoverflow for an overview of the issue and possible solutions
  2. Mark Kharitonov has compiled a basic set of instructions that allow installing MSTest on a Build Server

My setup consists of a Teamcity Build Agent running on Windows Server 2008R2 x64, so I needed to change all registry keys in the reg file to point at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ instead of HKEY_LOCAL_MACHINE\SOFTWARE\.

Next, I am using Gallio to run the tests instead of executing them directly using MSTest. Even though Gallio is considerably slower than native MSTest, which you can also use with a built-in Teamcity buildstep, there are a couple of advantages:

  1. Pretty Reports
  2. No need to deal with test run configurations and test metadata (I’ve got no idea what they are and why I would need them)
  3. Teamcity picks up the test resulty properly
  4. I can use a MSBuild script to pick up my Test dlls via wildcards, no need to have extra MSTest build tasks.

As a reference, here’s my MSBuild script for running the tests using Gallio:

<Project DefaultTargets="Test" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    
	<!-- This is needed by MSBuild to locate the Gallio task -->
    <UsingTask AssemblyFile="tools\Gallio\Gallio.MSBuildTasks.dll" TaskName="Gallio" />
    
	<!-- Specify the tests assemblies -->
    <ItemGroup>
        <TestAssemblies Include="src\test\**\bin\$(Configuration)\*Tests.dll" />
	</ItemGroup>
    
	<Target Name="Test">
        <Gallio 
            Files="@(TestAssemblies)"
            IgnoreFailures="true" 
            ReportDirectory="build\"
            ReportTypes="html"> 
            <!-- This tells MSBuild to store the output value of the task's ExitCode property
                 into the project's ExitCode property -->
            <Output TaskParameter="ExitCode" PropertyName="ExitCode"/>
        </Gallio>
		<Error Text="Tests execution failed" Condition="'$(ExitCode)' != 0" />
	</Target>
	
</Project>
Categories: .NET, Testing, Tools
%d bloggers like this: