I have a question about this approach.  Do you use CruiseControl.NET or some other continuous integration software?

If so, how do you integrate two separate unit test assemblies into one NCover code coverage report?  I don't need details, I'm just wondering if it's easy or hard to do.

I pretty much follow what you do for the most part. I'll blog about it soon because it's an interesting topic.

Jeremy,

Personally, I prefer the approach you dislike, in keeping a test assembly per each production-code assembly. It makes it far easier to keep things organized and clean, and frankly, it makes it easier and faster for *me* to run the tests, contrary to your experience. This is because I indeed rarely need to run the entire set of tests, except when I do a full build (either through CI or by hand, using either NAnt or MSBuild).

Now, I admit part of this has to do with my use of TestDriven.NET to run the tests, which makes it very easy and fast to run just the tests I like (a specific method, the entire class, the entire assembly), so this combination gives me all the granularity I need, particularly since I prefer the Test Fixture per Class style.

Jeremy,

I hear you, though I guess we'll just agree to disagree :)

Sure, build time is important, specially for large projects; though structure helps a lot (and splitting things into multiple solutions as well). I've handled large projects, using the structure I mentioned, without any problems, and without causing any hassle in maintaining the build. But, at least on VS.NET 2003, this pretty much meant abandoning the build system completely. Nant was pretty flexible in scenarios like this and there are some pretty good ways you can split your buildfiles so that all is done pretty much automatically for you when you add a new project (and the corresponding unit test projects).

So there are certainly ways around it :)

Haacked and Jeremy,

from my experience, NCover reports dont work right at all with two assemblies. There is no dependable merge mechanism for two NCover reports.

Thanks,

r.

I seem to remember that the key to getting a decent NCover report out of two assemblies is to merge the assemblies, not the report.

I also prefer the 1 unit test assembly per production assembly. The assembly is the atomic unit of deployment. If you have 2 production assemblies, the assumption is there is some scenario where they are used independently. In that case, you want the unit tests to be able to follow the assembly wherever it goes (use in other projects, etc).

Why do you have more than 1 assembly in your project, if your unit tests assume all the assemblies will always be used together? Why not just put all your production code in a single assembly and reduce your build times even more?

Seems like that NCover issue would be a showstopper for two assemblies.  Why not use two top-level namespaces in a single test assembly.

namespace Test.Integration

namespace Test.Unit

That way you can run the one namespace (since MbUnit, TD.NET both allow running tests for a given namespace. Can't remember if NUnit does).

Structuring Unit Test Code

We create a separate assembly for tests with a .Test suffix in the assembly name and namespace, and use InternalsVisibleTo as you mentioned. We label unit tests (I like calling them <a href="http://www.lukemelia.com/devblog/archives/2006/09/13/a-new-term-microtest/">microtests</a> now) and integration tests by using MbUnit's FixtureCategory attribute. We can then run whichever we want from the console and employed the TD.NET add-in architecture to make it tend to run unit tests only unless explicity requested to run an integration test. I documented this approach <a href="http://www.lukemelia.com/devblog/archives/2006/02/21/mbunit-testdrivendotnet-categoryfilter/">here</a>.

Jeremy has an excellent series of posts about getting started on a new project . He recently talked about

To merge NCover reports - just use NCoverExplorer.Console as part of your build script. There are NAnt and MSBuild tasks for it or else you can use the command line. You can also apply coverage exclusions at the same time to trim down the resulting report if you want.

Jeremy,

I organize my tests based on layers in my application. I have a unit test project for the UI, one for the domain, and another for the DAL. Inside each project I separate out test fixtures by folders (basically mimicking the heriachy in my domain project(s)) and create a test fixture for each concrete class.

The test assemblies have a .Test suffix to them so that I can ignore them in things like code coverage. NCover let's me just ignore any namespaces or assembly names via wildcards, so it lets me focus on the code I want to cover.

Works great.

I tend to have multiple projects for different tiers/architectural patterns (such as separated interface for remoting) and then just have one project for my nUnit tests.

I tend to just have unit tests that drive the implementation and then rely on fitness for integration testing (as fitness is testing what the customer is supposed to experience - don't duplicate test material).

KISS - Keep it simple stupid ;)

What do others think about my method of testing?

I've always gone for 1 assembly with all test-classes in that 1 assembly.  All the unit tests are in 1 spot and easy to test and a seperate from any production code..

Assembly (Class Library): Porsche.Carrera.Targa.NUnit.dll

class Porsche.Carrera.Targa.NUnit.TestHelper { //Had created this once when I had to create some crazy WebService created by the fellow before me with alot of initialization }

class Porsche.Carrera.Targa.NUnit.Acceleration {}

class Porsche.Carrera.Targa.NUnit.Handling {}

class Porsche.Carrera.Targa.NUnit.Braking {}

In the first approach of putting the TestFixture classes inside the production assemblies, I love the idea of being able to always find the unit test code directly under the production code.

But... How can I filter out the test code via the build automation scripts? If the two classes are in one file, then there needs to be a reference to the NUnit dll with the TestFixtures to be successfully compiled, yet I don't want to ship out the unit dll with the production code.

I need an example of NUnit testing with complete description and is it possible that if we change the parameters of a main function and when we test through NUnit all the sub fuctions parameters are chaged.

I need this.

Jeremy

I would rather keep my tests in a separate assembly. However, in many cases I have classes that are internal to my assembly, but which have behavior that I would like to test. Of course, I could test its behavior through the classes which ARE exposed and which use the internal class, but the behavior of the internal class is significant enough that I would prefer to test it independently. This is in the spirit of using unit tests to ensure that what I am writing is doing what I think it should as I write it. I don't see any other way to do that except to put the tests in the same assembly, or use InternalsVisibleToAssembly. Based on your stated preference, can I assume that you never try to unit test  internal types? In your opinion, should I trust that testing the externally exposed types is enough?

Since when is scoping about paranoia? Scoping is about controlling what users can see, not merely for the purposes of protecting the internals, but also for protecting the user! By controlling what users can take dependencies on, you control the extensibility of your library; otherwise your ability to refactor is extremely limited. You also guide users to the natural entry points into your library that it was designed for them to use, rather than making them dig through everything you have exposed trying to find something that is relevant to their situation.