Accessing Non-Public Member of Abstract Base Classes in Unit Tests

Given you have an abstract base class with non-public member, and a derived class with other non-public member too. Now you want to unit-test some of the non-public member (methods) of the derived class.

Prior the call of the method of the derived class, you need to set some non-public properties declared in the base class.

The problem I ran into was, that, using the derived class’ accessor, I was not able to access the properties of the base class. But without setting them, I can’t test the method.

The solution is somewhat uncommon, but it works. You need two private accessors, ‘pointing’ to the same object. Use the one to manipulate the base class’ member, and the other to access the derived class’ member. Since both accessors point to the same object, you do access that single object. See the code below:

DerivedClass instance = new DerivedClass();

BaseClass_Accessor baseAccessor 
  = new BaseClass_Accessor(new PrivateObject(instance, 
      new PrivateType(typeof(DerivedClass))));

baseAccessor.ProtectedProperty = someValue;

DerivedClass_Accessor accessor 
  = new DerivedClass_Accessor(new PrivateObject(instance));

accessor.CallMethodToTest();

Disable Control-Buttons of RadGridView

Using Telerik’s RadGridView, one can connect the add, update, cancel and delete command to RadButtons by setting the

Command="telerik:RadGridViewCommands...."

properties of the buttons and link to the grid by setting the

CommandTarget="{Binding ElementName=GridViewName}"

property.

For some reasons, I needed to disable the buttons, depending on the rights the currently logged in user has. Setting

button.IsEnabled = false;

during runtime did not work, for whatever reasons. But setting

button.CommandTarget=null;

during runtime, without disabling the button, worked fine. Resetting the button’s CommandTarget to the associated RadGridView re-enabled the button.

I tend to call this a bug. Luckily, there is an easy work around.

Silverlight Unit Test Headwords

At the time of writing, creating unit tests for Silverlight is not as smooth and easy as it is for .NET assemblies. My experiences base on the Silverlight toolkit published on Codeplex silverlight.codeplex.com.

  • You cannot access private or protected methods or properties. So use the #if DEBUG to make these parts of the class internal (in DEBUG mode).
  • Add [assembly: InternalsVisibleTo(“NameOfUnitTestAssembly”)] to the AssemblyInfo.cs of the library that contains the class to be unit tested. Of course, again only for DEBUG mode.
    Even access to non-public methods by reflection is not possible (security reasons).
  • For the unit test assembly, create a new Web project to host it. Otherwise, you need to switch the start page of the existing Web project.
  • Only create one unit test assembly for all Sliverlight assemblies you want to test. Doing so you will have a better overview.
  • Creating trace output is not possible. Although there is an ‘Output’ tag in the result page, there is no way to write output into it. Use the Debug.Write… and Sysinternals DbgView to view the trace if required.