How do you unit-test code that interacts with and instantiates third-party COM objects?

Question

One of the biggest issues currently holding me back from diving full steam into unit testing is that a really large percentage of the code I write is heavily dependent on third-party COM objects from different sources that also tend to interact with each other (I'm writing add-ins for Microsoft Office using several helper libraries if you need to know).

I know I should probably use mock objects but how exactly would I go about that in this case? I can see that it's relatively easy when I just have to pass a reference to an already existing object but some of my routines instantiate external COM objects themselves and then sometimes pass them on to some other external COM-object from yet a different library.

What is the best-practice approach here? Should I have my testing code temporarily change the COM registration information in the registry so the tested code will instantiate one of my mock objects instead? Should I inject modified type library units? What other approaches are there?

I would be especially grateful for examples or tools for Delphi but would be just as happy with more general advice and higher-level explanations just as well.

Thanks,

Oliver

Answer 1

It comes down to 'designing for testability'. Ideally, you should not instantiate those COM objects directly but should access them through a layer of indirection that can be replaced by a mock object.

Now, COM itself does provide a level of indirection and you could provide a mock object that provided a substitute for the real one but I suspect it would be a pain to create and I doubt if you'd get much help from an existing mocking framework.

Answer 2

I would write a thin wrapper class around your third party COM object, which has the ability to load a mock object rather than the actual COM object in the unit testing situation. I normally do this by having a second constructor that I call passing in the mock object. The normal constructor would have just loaded the COM object as normal.

The wikipedia article has a good introduction to the subject Wikipedia artible

Answer 3

The traditional approach says that your client code should use a wrapper, which is responsible for instantiating the COM object. This wrapper can then be easily mocked.

Because you've got parts of your code instantiating the COM objects directly, this doesn't really fit. If you can change that code, you could use the factory pattern: they use the factory to create the COM object. You can mock the factory to return alternative objects.

Whether the object is accessed via a wrapper or via the original COM interface is up to you. If you choose to mock the COM interface, remember to instrument IUnknown::QueryInterface in your mock, so you know that you've mocked all of the interfaces, particularly if the object is then passed to some other COM object.

Alternatively, check out the CoTreateAsClass method. I've never used it, but it might do what you need.

Answer 4

There are some arguments against using mock objects, or at least about their potential abuse.

You could consider setting up an isolated environment in a virtual machine and running more involved integration tests on the pieces that have external dependencies that are difficult or impractical to isolate.