Как вы тестируете модуль, который взаимодействует и создает экземпляры сторонних COM-объектов?

Question

Одна из самых больших проблем, которая в настоящее время удерживает меня от полного погружения в модульное тестирование, заключается в том, что действительно большой процент кода, который я пишу, сильно зависит от сторонних объектов COM из разных источников, которые также имеют тенденцию взаимодействовать друг с другом (Я пишу надстройки для Microsoft Office, используя несколько вспомогательных библиотек, если вам нужно знать).

Я знаю, что мне, вероятно, следует использовать фиктивные объекты, но как именно я поступил бы с этим в этом случае? Я вижу, что это относительно легко, когда мне просто нужно передать ссылку на уже существующий объект, но некоторые из моих подпрограмм сами создают экземпляры внешних COM-объектов, а затем иногда передают их другому внешнему COM-объекту из другой библиотеки.

Какой подход наилучшей практики здесь? Должен ли я иметь свой тестовый код временно изменить регистрационную информацию COM в реестре, чтобы протестированный код вместо этого создал экземпляр одного из моих фиктивных объектов? Должен ли я вводить измененные модули библиотеки типов? Какие еще есть подходы?

Я был бы особенно благодарен за примеры или инструменты для Delphi, но также был бы рад более общим советам и объяснениям более высокого уровня.

Спасибо

Оливер

Answer 1

Традиционный подход говорит, что ваш клиентский код должен использовать оболочку, которая отвечает за создание экземпляра COM-объекта. Эта обертка может быть легко издеваться.

Поскольку у вас есть части вашего кода, непосредственно создающие экземпляры COM-объектов, это не совсем подходит. Если вы можете изменить этот код, вы можете использовать фабричный шаблон: они используют фабрику для создания COM-объекта. Вы можете издеваться над фабрикой, чтобы вернуть альтернативные объекты.

Вопрос о том, доступен ли объект через оболочку или через оригинальный интерфейс COM, зависит от вас. Если вы решите смоделировать COM-интерфейс, не забудьте применить инструмент IUnknown :: QueryInterface в своем макете, чтобы вы знали, что вы смоделировали все интерфейсы, особенно если объект затем передается другому COM-объекту.

Кроме того, проверьте метод CoTreateAsClass . Я никогда не использовал его, но он может делать то, что вам нужно.

Answer 2

Все сводится к «проектированию для тестирования». В идеале не следует создавать экземпляры этих COM-объектов напрямую, а обращаться к ним через слой косвенности, который может быть заменен фиктивным объектом.

Теперь, сам COM обеспечивает уровень косвенности, и вы могли бы предоставить фиктивный объект, который заменял бы реальный, но я подозреваю, что это было бы трудно создать, и я сомневаюсь, что вы получите большую помощь от существующий насмешливый каркас.

Answer 3

Я бы написал тонкий класс-оболочку для вашего стороннего COM-объекта, который может загружать фиктивный объект, а не реальный COM-объект в ситуации модульного тестирования. Обычно я делаю это, имея второй конструктор, который я называю передачей в фиктивном объекте. Обычный конструктор просто загрузил бы COM-объект как обычно.

В статье в Википедии есть хорошее введение в тему. Википедия artable