<p>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).</p>

<p>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.</p>

<p>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?</p>

<p>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.</p>

<p>Thanks,</p>

<p>Oliver</p>

[{'answer_id': 70541, 'author': 'Steve Morgan', 'author_id': 5806, 'author_profile': 'https://Stackoverflow.com/users/5806', 'pm_score': 2, 'selected': False, 'text': "<p>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.</p>\n\n<p>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.</p>\n"}, {'answer_id': 70558, 'author': 'John Sibly', 'author_id': 1078, 'author_profile': 'https://Stackoverflow.com/users/1078', 'pm_score': 2, 'selected': False, 'text': '<p>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. </p>\n\n<p>The wikipedia article has a good introduction to the subject\n<a href="http://en.wikipedia.org/wiki/Mock_object" rel="nofollow noreferrer">Wikipedia artible</a></p>\n'}, {'answer_id': 70594, 'author': 'Roger Lipscombe', 'author_id': 8446, 'author_profile': 'https://Stackoverflow.com/users/8446', 'pm_score': 4, 'selected': True, 'text': '<p>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.</p>\n\n<p>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.</p>\n\n<p>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.</p>\n\n<p>Alternatively, check out the <a href="http://msdn.microsoft.com/en-us/library/ms693452.aspx" rel="nofollow noreferrer">CoTreateAsClass</a> method. I\'ve never used it, but it might do what you need.</p>\n'}]
['https://Stackoverflow.com/questions/70482', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/9784/']