IT Bytes

I’m currently looking at several Mocking tools to try and break various component dependancies when unit testing. So for example I want to unit test MyObject.SayHello(arg1) but that uses MyDataService.GetData(Request). When I unit test I don’t want to actually want to invoke MyDataService but simply assume a return value. That way I can unit test only MyObject and not worry about any incorrect behaviour (or setup problems) from MyDataService.

Looking at the options the majority of the Mocking objects work in the following fashion:

MyUnitTest()

MockObject("MyDataService.GetDate", "MyInputValue", "AssumedReturnValue");

MyObject.SayHello("Hello");

…..

What I really dislike about this approach is that to write the unit test I need to know alot of information about the services MyObject is going to call, I think this is wrong for a couple of reasons. 1. I wouldn’t assume the author of the unit tests knows anything about the services that will be called, especially in when using Extreme Programming and/or a second person other than the code component author is writing the tests 2. If the service changes you have a maintaince headache of revisiting all the unit tests to change their expected values.

I’ve got some ideas about;

a) having a centralised map of in’s and out’s (maybe with special codes in invoke real components)

<MyObject><UnitTestTypeA><MyDataService/>..

<MyDataService><UnitTestTypeA><in>bla</in><out>blabla</out>…

b) decorating the methods with example values

[UnitTestTypeA; In=bla;out=blabla]

MyDataService.GetData

c) the service components mock their own objects and the clients asks for all the mocks, so the code looks something like

MyUnitTest()

MyObject.GetAllMocks("UnitTestTypeA")

MyObject.SayHello("Hello");

…

i.e. would require reflection or interfaces an extra code in the components solely for Mocking

d) some combination of the above

I had a interesting reply from Joe Rohde, who seems to have some inside knowledge at Microsoft, that they are looking into producing something similar for a future realease of Visual Studio. That’s given me the push to look at implementing (c) probably using using something like reflection rather than interfaces that way it should be possible to maintain some form of map association with the actual component rather than implement code into the component. The first hurdle I can see is how to mock objects that are not simple types and do not support serialization.