A few upfront assertions:
- Unit testing is good. For C# code I use NUnit (along with TestDriven.NET).
- Languages (including C#) have been designed with the
internalkeyword for a reason. There are legitimate uses for something that's accessible only within one's own assembly. - These
internalclasses/methods are reasonable candidates for unit testing.
So, how do you test internal bits without compiling test code
into your deliverable assembly?
It turns out that it's trivial (in the .NET 2.0 Framework): Friend Assemblies (see also).
Say you have two projects: MyCoolAssembly and MyCoolAssembly.UnitTests.
- In your MyCoolAssembly, open up the Properties/AssemblyInfo.cs.
- Add
[assembly: InternalsVisibleTo("MyCoolAssembly.UnitTests")]
That's it! Now, MyCoolAssembly.UnitTests can access all of
the internal classes/methods within
MyCoolAssembly.
No conditional compilation symbols. No messy inner classes. Problem solved.
I found out about this useful attribute in CLR via C#, but Jay Bazuzi (whose blog I'd really like to read except that he apparently doesn't post anymore) had already blogged about this very usage back in September of 2004.
2 comments:
The problem with InternalsVisibleTo is that you immediately loose the "consumer perspective" on the code you're testing. I think this is an important benefit of doing test driven development.
I guess one possibility would be to have a separate test assembly for testing internal types. I can't however see myself doing it this way. I find my solutions quickly balloon even with one test assembly per test target (for testing public types).
I'm still looking for a good solution to this problem!
You know, I hadn't considered that the entire test assembly now becomes somewhat "omniscient". That's a good point.
Post a Comment