Возможно ли получить Анализ покрытия кода в сборке взаимодействия?

Question

Я также задавал этот вопрос на форумах MSDN и не нашел решения:

http://forums.microsoft.com/msdn/ShowPost.aspx ?postID=3686852иSiteID=1

Основная проблема здесь, как я вижу, заключается в том, что сборка взаимодействия фактически не содержит никакого IL, который можно было бы инструментировать (за исключением, возможно, нескольких делегатов).Итак, хотя я могу собрать тестовый проект, который использует уровень взаимодействия, я не могу получить представление о сколько их было из тех методов и свойств, которые я на самом деле вызываю.

План Б состоит в том, чтобы пойти и написать генератор кода, который создает библиотеку RCWWS (оболочек, вызываемых во время выполнения), и использовать это для целей покрытия кода.

Редактировать:@Франси Пенов,

Да, это именно то, что я хочу сделать.Поставляемые нам COM-компоненты представляют собой библиотеку из нескольких десятков DLL-файлов, содержащую ок.3000 типов.Мы используем эту библиотеку в нашем приложении, и нам поручено протестировать этот уровень взаимодействия, поскольку группа, предоставляющая нам библиотеки, проводит минимальное тестирование.Покрытие кода позволило бы нам гарантировать, что все интерфейсы и соклассы будут задействованы.Это все, что я пытаюсь сделать.У нас есть отдельные тестовые проекты, которые используют наш собственный управляемый код.

Да, в идеале команда COM-сервера должна тестировать и анализировать свой собственный код, но мы живем не в идеальном мире, и я должен предоставлять качественный продукт, основанный на их работе.Если я смогу предоставить отчет о тестировании, в котором указано, что я протестировал 80% их интерфейсов кода и 50% из них работают не так, как рекламируется, я смогу выполнить исправления там, где это необходимо, а не обходные пути.

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

Как я упоминал выше, следующим шагом будет создание оболочек для оберток и использование их в целях тестирования.

Answer 1

Чтобы ответить на ваш вопрос - невозможно использовать сборки взаимодействия для покрытия кода.Они содержат только метаданные и никакого исполняемого кода, как вы сами упомянули.

Кроме того, я не вижу особого смысла пытаться кодировать сборку взаимодействия.Вы должны измерять охват кода, который вы пишете.

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

Имхо, правильным способом сделать это было бы написать макет слоя для COM-объекта и проверить, что вы вызываете все методы / свойства, как ожидалось.

Answer 2

План С:

используйте что-то вроде Моно.Сесил встроить простые счетчики выполнения в сборку взаимодействия.Например, ознакомьтесь с этим разделом в Вопросы и ответы:"Я хотел бы добавить некоторые функции трассировки в сборку, которую я не могу отладить, возможно ли это с помощью Cecil?"