OT: NUnit Test Fixture Location

[Robert Cramer]

I'm learning NUnit and do not like the idea of keeping the test fixtures in
the same assembly as the classes being tested. But all of the examples I
have been able to find show either (1) the test fixture in the same assembly
and namespace as the test subjects, or (2) are moot on the location -
showing only the test fixture without any indication of where it is located.

I'd like to know what those of you with substantial experience do. Do you
have a separate project for all test fixtures - then include that project in
the same solution as the test subjects?

Yes - I have googled this a bunch and have come up with articles that
present NUnit in general, TDD, etc - but nothing specific about how to
organize test fixtures in projects and solutions.

Thanks!

 

[Cowboy \(Gregory A. Beamer\)]

First, I would not really consider this OT, as unit testing is an important
part of development. Rest inline.

I'm learning NUnit and do not like the idea of keeping the test fixtures
in the same assembly as the classes being tested. But all of the examples
I have been able to find show either (1) the test fixture in the same
assembly and namespace as the test subjects, or (2) are moot on the
location - showing only the test fixture without any indication of where
it is located.

Most examples on the web suck ... period. In fact, most examples in books
suck, as well. I do not mean they suck as far as teaching the concept, but
that they suck as far as best practices. You will also note that most
ASP.NET examples have all of their code either inline or in code behind. A
very bad practice, esp. for those engaging in unit testing. Microsoft's
solution to this bad practice, now passed on to the masses, is the MVC
Framework and Silverlight, both which force the separation of concerns.

I'd like to know what those of you with substantial experience do. Do you
have a separate project for all test fixtures - then include that project
in the same solution as the test subjects?

There are times I refactor into more than one, if there are tests that do
not have to be run every time, or I have extended beyond the unit (a unit
test should only test local code, with mocks/dependency injection for
outside code). But, I am always external. My norm, is something like:

CompanyName.LibraryName - tested assembly
CompanyName.LibraryName.Tests - all test as "sub" namespaces
CompanyName.LibraryName.Tests.VS - Visual Studio Tests
CompanyName.LibraryName.Tests.nUnit - nUnit Tests
CompanyName.LibraryName.Tests.mbUnit - mbUnit Tests

I am heading more towards either VS tests or mbUnit tests, although I still
have a lot of nUnit tests.

Yes - I have googled this a bunch and have come up with articles that
present NUnit in general, TDD, etc - but nothing specific about how to
organize test fixtures in projects and solutions.

Examine how Microsoft ships its tests with source code. The Enterprise
Library is a good example.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

*************************************************
| Think outside the box!
|
*************************************************

 

[Robert Cramer]

Thanks for the helpful feedback. A couple of quick followup questions:

1. By stating "... I am always external" - do you mean that your test
fixtures are always in a separate *project* (assembly) from the tested code?
Or merely in a separate file in the same project/assembly?

2. What is your opinion on this: Place the test fixtures in the same code
files as the tested code - but eliminate the test fixture from the output
assembly with conditional directives. IMO, the good thing about this
approach is that everything is in one place (convenient). The bad thing
about this approach is that everything is in one place (no separation of
concerns). Thoughts?

Again, I really appreciate your helpful feedback. I thought I was the only
person in the world NOT doing TDD and unit testing... so I was quite
surprised to find an utter lack of best practices documented on the
subject - and surprised by the lack of responses to my OP here - given the
calibre of developer in this NG. Maybe I'm inquiring about industry secrets
and didn't know it!

-RC