Я также задавал этот вопрос на форумах MSDN и не нашел решения:
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3686852&SiteID=1
Основная проблема здесь, как я вижу, состоит в том, что сборка взаимодействия на самом деле не содержит никакого IL, который может быть инструментирован (за исключением, может быть, нескольких делегатов). Таким образом, хотя я могу собрать тестовый проект, который реализует уровень взаимодействия, я не могу понять, сколько этих методов и свойств я на самом деле вызываю.
План Б состоит в том, чтобы пойти и написать генератор кода, который создает библиотеку RCWW (исполняемых обертываемых оболочек-оберток), и инструмент для целей покрытия кода.
Редактировать: @ Франци Пенов,
Да, именно это я и хочу сделать. Поставляемые нам COM-компоненты составляют библиотеку из нескольких десятков DLL, содержащих ок. 3000 видов. Мы используем эту библиотеку в нашем приложении и отвечаем за тестирование этого уровня Interop, поскольку группа, поставляющая нам библиотеки, проводит минимальное тестирование. Покрытие кода позволило бы нам обеспечить выполнение всех интерфейсов и классов. Это все, что я пытаюсь сделать. У нас есть отдельные тестовые проекты, в которых используется собственный управляемый код.
Да, в идеале команда COM-серверов должна тестировать и анализировать свой собственный код, но мы не живем в идеальном мире, и я должен предоставить качественный продукт, основанный на их работе. Если мне удастся создать отчет о тестировании, указывающий, что я протестировал 80% их интерфейсов кода и 50% из них работают не так, как было объявлено, я могу сделать исправления там, где необходимо сделать исправления, а не обойти проблемы.
Упомянутый вами макетный слой был бы полезен, но в конечном итоге он не достиг бы цели тестирования самого Interop-слоя, и я, конечно, не хотел бы поддерживать его вручную - мы во власти СМИД. ребята с точки зрения изменений в интерфейсах.
Как я уже говорил выше, следующим шагом является создание оберток для оберток и их использование в целях тестирования.