Unit Testing Internal methods.

Today I did some pair programming with Richard Banks from Readify.

When I explained to him that I use the IDE to generate these property accessors that use reflection to test internal and private methods he showed me a nicer way around it:

  http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx

Basically all I had to do was [assembly: InternalsVisibleTo(“Assembly Name”)] to the assembly.cs file and make sure that the “Assembly Name” was pointing to the unit tests assembly name.

This worked perfectly! Thanks Richard!

P.S I should state the obvious note that this approach doesn’t work for private methods

Unit Test Method Names

 I would like to share some experience with unit test projects in Visual Studio. When you run the unit tests  the method name is what is displayed in the result screen.

Take a look at this screen shot of my current project and you will know what I’m talking about:

Because the test name is what the unit tests method name is, it makes sense to create very long and descriptive method names. You will not be using these method names in code or anything the very long names wont turn into a readability problem. You are just running these tests to see the beautiful green ticks.

Important Note: One of the Failed unit tests that aren’t visible in the screen shot threw an exception of “Failed Can_Create_BackEnd_User Tests Test method OricaMiningServices.Tests.UserManagerTest.Can_Create_BackEnd_User threw exception:  System.NotSupportedException: Specified method is not supported.. ” The exception is being thrown by the create method of the asp.net Membership class. The exception when stepping through the debugger is “Password is not strong enough” but the error message that appears in the test result window is the previous copy pasted error. Huh? What gives. When I step through the web application I can a password not strong enough error. When the unit test tries to access the method I get a different exception?! After 5 minutes of scratching my head it hit me. (Well, this is my guess anyway) There is no HTTP context for the unit test to run on, and there for none of the asp.net membership provider stuff can possibly work. For example, who are you authenticating? The Unit Test? It’s no me (Robert) that is running the application it’s visual studio’s unit test project. Anyway in my opinion this is a bug and should be fixed because it makes unit testing the whole user security layer slightly more complex.