views:

86

answers:

1

I am trying to retrofit unit tests on to some existing code base. Both the class and method I want to unit test is decorated with custom attributes that are inherited from ContextBoundObject and ContextAttribute. I dont want them to run as part of the unit test.

The only solution I have come up with is to compile the attribute out when I want to unit test. I dont really like this solution and would prefer to either replace it with a mocked attribute at runtime or prevent the attribute from running in a more elegant way.

How do you unit test code that has class and method attributes that inherit from ContextBoundObject and ContextAttribute that you dont want to run as part of a unit test?

Thanks in advance.

+2  A: 

Classes that inherit from ContextBoundObject execute methods by passing messages rather than the traditional stack-based execution model. This ability is used as the foundation for remoting and COM interop. One of the interesting options is that it becomes possible to intercept method calls using attributes, which allows for a kind of "poor mans AOP".

One of the options for getting rid of the logic provided by the attributes would be to create a configuration file to override which class gets created when you new your class. This ability is only available to classes inheriting from MarshalByRef, which is the base class for ContextBoundObject.

Another option might be to create an instance of the class using reflection. That is, to locate a particular ConstructorInfo and invoke it to create an instance. When you simply "new" an instance the call is routed to Activator.CreateInstance, which probably gives you a proxy object for the actual class. Creating the object directly might bypass this, although it's a shot in the dark.

Morten Mertner
I was hoping there was going to be a better way. These are very good suggestions though, thanks.
Joel Cunningham