Should Unit Tests be in their own project in a .Net Solution

views:

263

answers:

+2 Q:

Should Unit Tests be in their own project in a .Net Solution

Should I start a new project for my unit tests? That would mean that I would get two executables correct? Then I am worried about the namespace organization. Would I be able to put the unit test in the same namespaces as the classes that they are testing although they are part of a different project?

This raises another question. I know that namespace naming convention is CompanyName.TechnologyName.Feautre.Design. How would I get this right in my solution/project layout? Does the solution name = companyname, project name = technology name?

If that is the case does that mean I can't separate my unit tests into a new project.

Yes. Create a unit test project for each solution project.

There will only be a single executable. The units tests are held in a DLL.

Why not append 'UnitTests' to the relevant namespace.

Mitch Wheat 2010-02-12 10:06:51

I have been using access modifiers because I don't want to expose the internals of my classes. But I did want to unit test them so I made them package private (Sorry I come from a Java background).

uriDium 2010-02-12 10:11:42

+1 A:

1 test project per solution with folders => regression/integration/unit which has subfolders that 'mirrors' your solution project/folder architecture.

Remember - tests ain't your production code. They should be separated.

Arnis L. 2010-02-12 10:07:56

Interestingly, I know of one company that ship the tests with their application. In fact, they are runnable from the application. Makes more sense for Integration tests, I suppose...

Mitch Wheat 2010-02-12 10:11:02

@Mitch Wheat Don't get me wrong. It's fine to ship them too (3rd party tools does that all the time (e.g. nunit itself)), but they should be logically and physically (assembly, java package, whateva) separated. That's just how i see it. :)

Arnis L. 2010-02-12 10:16:28

@Arnis L.: Absolutely. Didn't mean to imply that they shouldn't be seperate.

Mitch Wheat 2010-02-12 10:21:29

+7 A:

The best approach is to have a separate unit test project per 'production project'. This ensures that you can vary and move them around in pairs.

If you have one unit test project covering more than one target project, this creates an artificial tight coupling between these two projects, because you will not be able to compile the unit test project without all of its target projects. This, again, makes it really hard to test a single project in isolation - which is what unit testing is all about.

It's very important to keep unit tests in separate libraries, because this ensures that you test only the public API of your code (black box testing).

I name my namespaces by appending "UnitTest" after the target namespace.

Mark Seemann 2010-02-12 10:10:21

Bunch of projects slows down everything. Any arguments against 1project 4 solution?

Arnis L. 2010-02-12 10:12:37

@Arnis L.: 1 unit test project per solution creates an artificial tight coupling between the solution and the target projects. Imagine that you want to reuse one of your project in a different solution, but you still want unit test coverage of that project in that new solution. This isn't possible because the single unit test project couples several projects. I've been there and suffered under it, and I never want to do that again.

Mark Seemann 2010-02-12 10:18:26

That didn't convince me. It's developers fault if he references `Tests.UI.Something` namespace from `Tests.Core.Something`. Only reason for separating tests in multiple projects - if you are *forced* to unit test one particular project in isolation. Good old YAGNI. :)

Arnis L. 2010-02-12 10:23:52

@Mark Seemann I've been in somewhere else too - where there are hundred projects with hundred unit test projects and build time hits eternity. And for what? For nothing. App was used and tested as a whole every time. :)

Arnis L. 2010-02-12 10:27:09

@Arnis L.: That's not what I'm saying. Imagine that your solution contains LibraryA and LibraryB (both production code). If you have only a single unit test project that targets both LibraryA and LibraryB, you will need to reference both LibraryA and LibraryB from the unit test project. Now, if you want to reuse LibraryA (but not LibraryB) *and its unit tests* in a new solution, you can't, because the unit test will not compile if LibraryB is not present as well.

Mark Seemann 2010-02-12 10:29:46

@Arnis L.: If you *must* have hundreds of projects in your solution you have tightly coupled code. Your problem isn't whether you have 1 or x unit tests projects as well - your problem is tight coupling. Constraining yourself to a single unit test project in such a case is only **treating the symptom**. A better solution is to deal with the root issue.

Mark Seemann 2010-02-12 10:32:53

@Mark Seemann i got that. The thing is - if you are developing ecommerce app for one client - you just won't need that. You won't reuse this application specific code elsewhere (and if tests are written correctly, it shouldn't be hard to separate them in different projects). Therefore - separating tests is just losing time because of build. I think you should agree that we are both right. :) Btw, are you aware of Jeffrey`s 'Onion architecture'?

Arnis L. 2010-02-12 10:34:47

@Mark Seemann now that's a truly good point - about tight coupling. But that particular case with hundred projects was bad architectural decision which wasn't made by me. Project had ridiculous architecture in general. Lately found function with ~60 lines where only real logic was 1 `string.IsNullOrEmpty(parameter)` (everything else - comments, tracing and whatnot).

Arnis L. 2010-02-12 10:38:15

@Arnis L.: I believe that the argument about not needing to reuse parts of an application elsewhere is a self-fulfilling prophesy because it will cause you to implement it such that this is indeed not possible, even if it should later become desirable. However, if you were to isoloate a Domain Model, it's very likely that this part could be used again - e.g. as a web service that provides an automatable interface to the original application.

Mark Seemann 2010-02-12 10:54:39

@Mark Seemann Maybe. Must admit that this approach is recently addopted. I still think that it shouldn't be a problem to snap out domain project test part if needed. I'll try to remember to keep you informed if this approach somewhere in future will leave me with pants down. :)

Arnis L. 2010-02-12 10:58:23

+2 A:

I tend to have a specific test project/assembly per assembly. The test assembly will have the same name as the assembly it is supposed to test, with the addition of the .Test in the name and the namespace.

That way, you keep your tests isolated and they do not get deployed with your production code.

Wim Hollebrandse 2010-02-12 10:14:50

Yes. Your unit tests should be a separate project, which compiles to its own DLL.

This means you're not deploying test code along with your project - and it encourages good design (since your tests can't see private/internal properties, you'll naturally tend towards testing those bits of your project which interact with other systems, rather than getting fixated on testing every detail of their internal implementation)

In terms of naming, we normally pick a "codename" for each project - current one's called Zanzibar - and then end up with projects like:

MyCompany.Zanzibar.Website (ASP.NET MVC web application)

MyCompany.Zanzibar.Website.Testing (contains unit tests for MVC web app)

Dylan Beattie 2010-02-12 10:15:12

ansaurus

tags:

views:

answers:

Should Unit Tests be in their own project in a .Net Solution

related questions