Testing Strategies - Organizing Your Tests

[Matt R]

I'm curious how other unit tester are organizing their Unit Tests.
I've read articles about the whether or not to put your unit tests
into the same project as your source code, or into a separate project
exclusively for your unit tests.

Back when I started, I kept my unit tests in a separate project. Then,
I started writing internal classes (because I had no reason to make
them public). This, in turn, prompted me to put my unit tests in the
same project (so they had access to the internal classes). Now, I'm
looking back on my reasons for making classes internal vs. public, and
I'm weighing the trade-offs. I have no reason to ship my unit tests
with my production code and, while it is a small footprint in the
overall EXE or DLL, it's still unnecessary overhead.

...So, back to my original question: How are you organizing your unit
tests? Do you write internal classes, or do you stick with public
classes?

[Javier G. Lozano]

I would add to your list of questions: how you're structuring/
refactoring your code to make it easier to test?
For example, when I do unit tests, I test the public interface for my
exposed classes and I provide two constructors one allow allow the
caller to inject their impl of the dependency and the default one that
injects my dependency. I generally don't test my internal classes
since they're pretty basic. If I need to test them or run into an
issue that forces me to, then I change their visibility to public.

My unit tests live in a separate assembly that in turn functions as a
consumer of my API.

[Evan]

The decision between same project/different project is a common issue
we face here at work. One of my co-workers only tests the public
methods so he wants to put his unit tests in a seperate project but I
like to test the protected methods as well. I like the "cleaner" look
to my unit tests when I am only testing the flow of 1 little method
instead of testing a public method that calls 6 or 7 smaller methods.
But, I agree with him in the fact that he never has to ship testing
code.

It should be noted that I don't have the easiest code to test since I
was a late adopter of unit testing on my current project. So, most of
my need to unit test the protected methods are because my public
methods are calling the database.

If you look at this web site: [http://codebetter.com/blogs/karlseguin/
archive/2007/12/20/foundations-of-programming-part-5-unit-
testing.aspx] he talks about placing the tag [assembly:
InternalsVisibleTo("CodeBetter.Foundations.Tests")] in the Assembly.cs
file to allow your testing namespace access to your private/protected
methods. This only works on 2.0+.

[Matt R]

Jav - I hate to add production code purely for testing, so I wouldn't
be a fan of adding a second constructor purely for testing.

Evan - Thanks for that web site reference. I really like that assembly
suggestion! Too bad it's not supported in .NET 1.1.

Thanks for the input guys!

[Nick Parker]

Matt,

Are your classes responsible for newing up their dependencies?

[Matt R]

I guess it depends on whether I want the ability to mock them or not.
If I have the intention of mocking them, I generally try to design it
from an IOC perspective.

> --
> Nick Parkerwww.developernotes.com- Hide quoted text -
>
> - Show quoted text -