How to use NUnit in multi-developer environment.

[Peter Rilling]

My development team is using VS.NET with VSS integration. They are able to
check in and out from within VS.NET. We also use NUnit for testing our
libraries. Currently our entire solution is checked into VSS along with all
the associated projects. Many developers need to work on the same solution.

The problem that I am having is getting a consistent unit test system setup
so that it can easily be shared. Basically, in order to run unit tests with
NUnit, we have an additional project in the solution that contains just the
test fixtures. Since that is part of the solution, it needs to be uploaded
to VSS. This is also desired since different people may need to add test
cases for their parts of code.

The problem is that I cannot determine a clean way for the developers to
share the test harnesses because the properties for the unit test project
requires absolute paths to the nunit.framework.dll and the nunit-gui.exe, as
well as an absolute path to the assembly that contains the test fixtures.
Since these are absolute, they break when different developers download the
projects. We do not necessarily have the same directory structures and
therefore VS.NET may not always be able to locate the absolute paths.

So, I would like to know how other people have solved this type of problem.

 

[Jon Skeet [C# MVP]]

My development team is using VS.NET with VSS integration. They are able to
check in and out from within VS.NET. We also use NUnit for testing our
libraries. Currently our entire solution is checked into VSS along with all
the associated projects. Many developers need to work on the same solution.

The problem that I am having is getting a consistent unit test system setup
so that it can easily be shared. Basically, in order to run unit tests with
NUnit, we have an additional project in the solution that contains just the
test fixtures. Since that is part of the solution, it needs to be uploaded
to VSS. This is also desired since different people may need to add test
cases for their parts of code.

The problem is that I cannot determine a clean way for the developers to
share the test harnesses because the properties for the unit test project
requires absolute paths to the nunit.framework.dll and the nunit-gui.exe, as
well as an absolute path to the assembly that contains the test fixtures.

Since these are absolute, they break when different developers download the
projects. We do not necessarily have the same directory structures and
therefore VS.NET may not always be able to locate the absolute paths.

So, I would like to know how other people have solved this type of problem.

Does it matter if each developer has their own unit test project?
They'll still all be testing the same code, just at different
locations. Just don't have the unit test project in VSS. I can't think
that the unit test project would need any settings which you'd want to
have shared, but please correct me if I'm missing something.

 

[Peter Rilling]

Well, first, the unit tests should be in VSS because they are code and they
should be under SCC just like any other code. That way we can view the
history and be protected in case data is lost on a developers' machine.

Next, our dev leads may want to be able to run the unit tests to verify that
nothing has broken. This is a procedural issue in our organization.

Next, what about developers who work on the same classes and methods. The
reason for having a single unit test environment would be to ensure that any
changes a developer makes did not compromise the code integrity. If each
developer had their own unit test project on their local machine, those
tests would be geared toward the code they worked on and may not take into
account code that was previous implemented. There may be business rules
that are not apparent in methods that changes could break. If all
developers were about to run all unit tests from all other developers, it
would ensure quality code.

Next, some of our projects have their solutions uploaded in VSS. That means
that all developers would have to be working from the same set of projects,
no more, no less. Otherwise the solution would need to be checked out each
time someone wanted to add their own custom projects and then break break
other developers.

Finally, we want to run the unit tests each night during the automated build
process. That means they have to be with the rest of the project so the
Anthill can fetch them.

 

[Michael Kennedy [UB]]

Hi Peter,

Have a look at HarnessIt as an alternative to NUnit.

http://www.unittesting.com

HarnessIt uses *relative* paths in its project files so is perfect for
source control. Additionally, it has a developer specific settings file much
like the .csproj.user in Visual Studio for certain settings that needs to be
stored specific to a particular developer and should be outside version
control.

Here's a breif document in our help discussing HarnessIt and source control.


http://www.unittesting.com/documentation/frameset.aspx?page=Tips/VersionControl.html

(watch for URL wrapping)

Regards,
Michael

Michael Kennedy
Partner, Software Engineer
United Binary, LLC
http://www.unittesting.com

 

[Jon Skeet [C# MVP]]

Well, first, the unit tests should be in VSS because they are code and they
should be under SCC just like any other code. That way we can view the
history and be protected in case data is lost on a developers' machine.

Yes, and I didn't disagree with that at all.

Next, our dev leads may want to be able to run the unit tests to verify that
nothing has broken. This is a procedural issue in our organization.

Absolutely.

<snip>

I think you've misunderstood my suggestion. The actual unit tests,
fixtures etc should all be in VSS. That doesn't mean everyone's NUnit
*project file* which just defines where things are needs to be in VSS.
You would probably want one version for the build machine in VSS, but
that doesn't mean that needs to be the one that everyone else uses.

All the *code* ends up in VSS - just not the *.nunit project file,
which could contain the absolute references if necessary. (In fact,
having just tried a simple project in v2.1, I'm not sure the references
*need* to be absolute, but that's another matter.)

 

[Michael Giagnocavo [MVP]]

One way to get around these problems in general is creating a virtual drive
(mapping a UNC path, or using subst) that's the same on every dev machine.

-mike
MVP

 

[Kevin Gale]

In general I find sysinternals junction a great tool for fixing absolute
or fixed in stone path problems

http://www.sysinternals.com/ntw2k/source/misc.shtml#junction