How do you unit test different class access levels?

Question

I admit - I'm a complete novice when it comes to unit testing. I can grasp the concepts easily enough (test one thing, break-fix-test-repeat, etc.), but I'm having a bit of a problem getting my mind around this one...

I've been tasked with rewriting a large section of our application, and I've got the class structure down pretty well. We have our test projects mixed right in with the rest of the solution, and all the references are lining up the way we want them to. Unfortunately, there are a few Friend classes that can only be accessed from inside the same namespace. As it stands, the test class is not a member of this namespace, so I cannot get direct access to any of those underlying methods, which REALLY need to be tested.

From what I've been reading, I could create a public mockup of the classes in question and test it that way, but I'm concerned that down the road someone will make a change in the production code and not copy it out to the test code, defeating the purpose of testing entirely. Another option would be to change the access level on the classes themselves, but that would involve a lot of overhead and fiddling with the code already in place. The idea of writing an interface has also come up, but creating a whole structure of interfaces for the sake of testing hasn't flown in management.

Am I just missing something here? What would be the best way to make sure those underlying classes are indeed functioning correctly without changing the access to them?

Answer 1

I'm not sure if you refer to .NET/C# projects, but you could add the InternalsVisibleTo attribute to the AssemblyInfo.cs file, to expose your internal classes to the unit test assembly.

Let's say you create a unit test project called "MyApplication.Tests", add this to the "MyApplication" project AssemblyInfo.cs file (located under "Properties"):

[assembly: InternalsVisibleTo("MyApplication.Tests")]

Answer 2

You can also make a subclass of the test-subject that is in the same namespace as the test-subject, and the subclass could expose whatever features necessary for testing.

Assuming you have some way of giving this subclass a "test" scope, you're home free. (You dont want this class in your regular code since it breaks encapsulation)

Answer 3

I think that your unit tests should not require anything of the source code, so the first answer certainly works. Have you considered using Reflection? I think it gets around changing the source code; there's a good discussion of this here: CodeProject