Can I specify a list of assemblies to test in a file?

I have a TeamCity build configuration that builds some code (several projects) and then runs their NUnit tests. Currently, I have to specify the test assemblies in the "Run tests from" section of the build step.

Is there any way of passing in the name of a file that is checked into source control that contains this list?

The reason I ask this is that we typically work with several branches. When someone branches the (trunk) code branch, they set up a new TeamCity build project for their branch. If they add a new (code) project on this branch that has tests, they will add this new assembly name to the TeamCity build configuration. When the branch gets merged back into trunk, they will remove their TeamCity build project, but it is easy to forget that as part of the merge process they must also now edit the TeamCity build configuration for the trunk to add the new assembly to it. If we could get the list of assemblies from a file that is part of source control, this file will get merged along with the code and its changes will then get picked up automatically in the trunk.

6 comments
Comment actions Permalink

Hello,

This is possible to list assemblies in text files. To implement this you need to write an MSBuild/NAnt build script that loads this file and put the values into properties.

On the other hand, you may use wildcards for this. Wildcards are supported in NUnit build runner. MSBuild/NAnt provides native wildcards support too.

0
Comment actions Permalink

This is possible to list assemblies in text files. To implement this you need to write an MSBuild/NAnt build script that loads this file and put the values into properties.


So I can have a task that loads the names of the assemblies into some property - which property is it, and how do I configure the NUnit runner in TeamCity to run NUnit over each assembly?

On the other hand, you may use wildcards for this. Wildcards are supported in NUnit build runner. MSBuild/NAnt provides native wildcards support too.



We tried using wildcards, but it didn't work. We have lots of projects with references between them. We have three projects:

ProjectA
     Contains some code. References ProjectB.
ProjectATests
     Contains tests for ProjectA. References ProjectA.
ProjectB
     Contains some code.

When we compile, the output directories look something like:

ProjectA
  bin
     ProjectA.dll
     ProjectB.dll
ProjectATests
  bin
     ProjectATests.dll
     ProjectA.dll
     ProjectB.dll
ProjectB
  bin
     ProjectB.dll

Because ProjectA has a reference to ProjectB, ProjectB.dll appears in its bin directory. If I say to run tests from ProjectATests.dll and ProjectB.dll using wildcards (or even just *.dll), ProjectB's tests get run twice as the dll is in two places. Multiply this up to near on 100 projects with lots of dependencies and it becomes unmanagable.



Any way to make it work would be good.
0
Comment actions Permalink

Does "*Test/bin/*Test.dll" work?

0
Comment actions Permalink

Unfortunately not. We have legacy code where some of the projects contain both implementation and test code (it is not easy to unpick this), meaning that the assembly is called ProjectB.dll and there is no indication on whether it is a test assembly or not.

We are working towards where that solution might work, but we have a lot of code to change before we are there.

0
Comment actions Permalink

The idea is even if NUnit runner cannot be configured in a way you need, there are other options to launch NUnit tests in your build.
For example, it can be put into MSBuild script:

<ItemGroup>     <TestList Include="testlist.txt"/> </ItemGroup>    <Target Name="NUnit">     <ReadLinesFromFile File="@(TestList)" >       <Output TaskParameter="Lines" ItemName="TestAssembly"/>     </ReadLinesFromFile>     <NUnit ToolPath="c:\Programs\NUnit-2.5.9.10348\bin\net-2.0" Assemblies="@(TestAssembly)" /> </Target>


and executed as additional target within MSBuild runner.

Michael
0

Please sign in to leave a comment.