Posts Tagged ‘InternalsVisibleTo’

Testing internal classes without making them public

May 15th, 2013

…with a trick to make private methods testable too.

When doing automatic tests one often wants to get to the internal classes.

Testing internal stuff

The possibly simplest way is to use InternalsVisbleTo and write


in the testee’s AssemblyInfo.cs

Or one can write just before the namespace declaration too

namespace Whatever{
class Hello{

<shrugging shoulders>Thats all there is to it.</shrugging>

The namespace is System.Runtime.CompilerServices.

One can decorate InternalsVisibleTo with keys and stuff to harden who gets to the internals but why bother? As long as it is dotnet some reflection can get pass the threshold anyway.

Testing private stuff

Another way I have used is to make a wrapping class “UT_Customer” or method “UT_Create” that 1) wraps the internal class/method, 2) is public and 3) is clearly marked with something conspicuous like “UT?_”. If a drive by programmer sees a method with a weird name and doesn’t bother to read the xml comments and still uses the method and fails; I consider it his fault, not mine. Not that I would use an undocumented method, no never.

private int AddCustomer(Customer customer){...}

internal int UT_AddCustomer(Customer customer){
return AddCustomer(customer);

Moq caveat

There is a caveat where interfaces are not visible for Moq as described here.

The symptom is an error message like

Message: Initialization method Base.UnitTests.Command.CommandHandlerTest thre exception.
Castle.DynamicProxy.Generators.GeneratorException: Type Base.Command.IUndoRedoStack[[Base.Command.ICommand, Base, Version=, Culture=neutral, PublicKeyToken=null]] is not public. Can not create proxy for types that are not accessible.

The remedy is to add