views:

185

answers:

1

Edit: Language/Platform is C# / .Net

I'm currently trying to fill a vast unit-test void in my current project, and being admittedly new to TDD, find myself quite stumped as to how to go about testing some of the more business-critical features.

I picked up Moq and had an easy enough time doing simple mocks, however at the core of my application lies a rather large, scary COM interop layer, which I'm having a difficult time conceptualizing how to Unit Test appropriately. The COM component is entirely 3rd party, and thus cannot be modified, and implements what amounts to a finite state machine for handling phone calls. The component notifies my application through a set of non-virtual events which I would like to test in certain orders to simulate state changes, however Moq does not offer a way to do this for anything but virtual events.

So my question to the more knowledgeable TDDers/Mockists is: How would you go about testing this sort of thing?

Apparently TypeMock supports this (in exchange for it's own shortcomings), but I'd rather not use it for a variety of reasons regarding type-safety and my general feeling that it's doing something devious behind my back.

+1  A: 

You can only mock virtual/abstract methods, unless you use something heavy-duty like TypeMock.

When you have to test code that you don't have control over, you're going to have to break your dependency on that code. Create a facade that has the methods, properties and events of the untestable class. Stick with the ones that you actually use; it'll keep down on the size of the code you have to write. Code against the facade you control rather than the code you don't.

The last thing is to use one of the several techniques to access the the facade that will allow you to substitute a mock during tests. You can use config files, dependency injection frameworks, lazy instantiation, etc. This way you can mock out your facade and use it for unit tests. Of course, you'll still have to do some integration tests to make sure your facade works correctly with the actual COM interop class.

For some inspiration, take a look at System.Web.Abstractions. It contains many classes which wrap ASP.NET core classes to make them mockable.

Will
I really appreciate the well thought out response, but it seems like this still runs headlong into the crux of the problem in that there will always be an untestable interaction between the COM component and some layer of abstraction. Maybe my understanding of TDD philosophy is fundamentally flawed...
TheMissingLINQ
Nope. You're pretty much right. But then again, nothing's perfect.
Will

related questions