Можно ли получить анализ покрытия кода на сборке взаимодействия? - PullRequest
4 голосов
/ 19 сентября 2008

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

http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3686852&SiteID=1

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

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

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

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

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

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

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

Ответы [ 2 ]

1 голос
/ 29 сентября 2008

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

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

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

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

0 голосов
/ 30 сентября 2008

План C:

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...