Errr, some catchy title.... RSS 2.0
 Wednesday, August 29, 2007

Below are two quick tips for testing non public classes and methods. I am not saying that it is a best practice to test your non public methods (usually indicates that there is something wrong with the design), but sometimes you just have to do it :).


Testing internal classes:



  1. Right click your test assembly.

 

2.Select a file

3.Instead of clicking Add, select 'Add as Link'.

 



Next, comes up testing non public methods:


The code below uses MbUnit testing framework (much better then NUnit). MbUnit has a class called Reflector which allows you to test non public fields, properties and methods. The only problem with this is the same one I have with many of the mocking frameworks: all of the names of properties and methods must be passed as strings, therefore there is no compile time validation. But hey, you can't have everything. :)


internal class ItemProcessor

{

      public ItemProcessor (List<ItemAttributeRiskFactor> attributeRiskFactors)

      {....}

.......

.......


      private bool CheckIfItemAttributeRiskFactorCorrespondsToItemAttibute(ItemAttributeRiskFactor risk,

                                                                                                                        ItemAttribute attribute)

      {

            if (risk.AttributeId == attribute.Id &&

               risk.AttributeValue == attribute.AttributeValue)

                     return true;

            return false;

      }

  }


The above code, is from one of my pet projects so you must forgive me that you don't understand what the class does. The important thing is that the class has private method that I want to test.

Below is the test code.



using MbUnit.Framework;

using MbUnit.Framework.Reflection;


[TestFixture]

class ItemProcessorFixture

{

   private Reflector reflector;

   private ItemAttribute attribute;

   private ItemAttributeRiskFactor risk;


   [TestFixtureSetUp]

   public void FixtureSetup()

   {

         ItemProcessor processor = new ItemProcessor(new List<ItemAttributeRiskFactor>());

         reflector = new Reflector(processor);

   }


   [SetUp]

   public void TestSetup()

   {

         attribute = new ItemAttribute();

         risk = new ItemAttributeRiskFactor(4, "HIGH", 50, false);

   }


   [Test]

   public void ItemAttributeAndItemAttributeRiskFactorShouldCorrespond()

   {

         attribute.Id = 4;

         attribute.AttributeValue = "HIGH";


         Assert.IsTrue((bool)reflector.InvokeMethod(

                     "CheckIfItemAttributeRiskFactorCorrespondsToItemAttibute", risk, attribute));

      }

   }


The interesting part of the code are in bold. We use MbUnit's Reflector class to test private method of the ItemProcessor class. Furthermore, the Reflector allows us to set and get fields and properties.

Overall, while it isn't a perfect way to test non public methods, it sure is better then not testing them at all :).

Wednesday, August 29, 2007 3:42:36 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
Testing | TDD
 Thursday, August 09, 2007

Developing an application that supports plugins is not an easy feat. Below are some links that will help you start the ball rolling:


One from CodeProject. Next one is from Roy Osherove on MSDN. Actually, it has two parts. Part one and two. After reading those you will have general idea what you should do. How to start, how to look for appropriate plugins and so forth. I would like to point out a few things more you should take into consideration.


First of all, what will the communication between the application and other plugins look like. How and if the plugins send any information to the hosting application. This of course depends on your applications requirements.


Another big one after communication is how will you visually present the plugins. If they are to be presented in the UI (added to be MainMenu or ContextMenus) the framework must allow it. Also remember not to pass references to your menus, because plugins would be able to delete some entries there. Rather allow a plugin to specify location and items that should be added to menus. This will be safer. (When returning those objects the plugin should already have attached the required event handlers).


Exception handling is also very important. How will you act when your plugin will throw an unhandled exception? Will the whole application crash or will it report gracefully that there was a problem with a certain plugin? For WinForms development there are two events you should register to: Application.ThreadException

AppDomain.UnhandledException.



On the final note, there is dnrTV Show on plugins in .NET. Be sure to watch it.

Thursday, August 09, 2007 2:32:09 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
Other
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2008
Marcin Waligora
Sign In
All Content © 2008, Marcin Waligora
DasBlog theme 'Business' created by Christoph De Baene (delarou)