C# / Visual Studio: production and test code placement

Question

In JavaLand, I'm used to creating projects that contain both production and test code. I like this practice because it simplifies testing of internal code without artificially exposing the internals in a project's published API.

So far, in my experiences with C# / Visual Studio / ReSharper / NUnit, I've created separate projects (i.e., separate DLLs) for production and test code. Is this the idiom, or am I off base? If this idiomatically correct, what's the right way to deal with exposing classes and methods for test purposes?

Thanks,

-Patrick

Answer 1

Testing internal code is easy: use [InternalsVisibleTo] to make your production assembly "trust" your test assembly. The test assembly will then have access to all the production assembly's internal members.

The MSDN documentation linked above gives an example. It's very simple.

You should definitely separate the two out as you're doing though, IMO. You don't really want your test code (or data) to end up in production assemblies.

EDIT: Just to respond to Steven's point about testing internals: I think it's entirely reasonable to test internals. I treat unit tests as white box tests, not black box. There's definitely a place for testing only the public API - particularly for integration tests - but I find there are plenty of places where it makes sense to test internal members. Heck, without that ability, how are you going to test internal types? Sometimes a relatively small public API is layered on top of a complex internal implementation - and testing units of that implementation can be tricky through just the public API.

It does make the testing potentially more brittle, in that internal implementation changes can require test changes which wouldn't be needed if you were only testing public APIs... but it can also make the production code more robust, as you're more likely to write copious tests for corner cases etc if it's easy to do so.

Moderation in all things, basically.