Microsoft Moles, динамический инструмент

Родинки можно использовать двумя способами:

Вручную

  1. Включая [сборку: MoledType (typeof (_type_to_instrument))]
  2. Укажите [HostType ("Moles")]
  3. Вызов Microsoft.Moles.Framework.Moles.MoleRuntime.SetMole (делегировать _stub, объект _receiver, метод MethodInfo);

Динамически

  1. Добавить {название проекта} .moles файл: указание сборки для моль. например
  2. Создайте и включите ссылку на MolesAssemblies / {project_name} .Moles.dll
  3. Используйте M {class_name} автоматически сгенерированные классы кротов.

Я заметил, что использование динамической сборки не работает требовать, чтобы в тестовом проекте были объявлены атрибуты «moled assembly». Это снижает накладные расходы,а разработчику нужно только украсить каждый метод тестирования типом хоста для родинок; но дальнейшее тестирование не требует отслеживания типов инструментов.

Глядя на автоматически сгенерированный код (с использованием дизассемблера) в сборках molesassemblies, легко найти необходимые атрибуты инструментария. Однако попытка написать мою собственную «сборку крота», по существу заменяющую автоматически сгенерированную, не работает, и среда выполнения жалуется, что мой тип нужно инструментировать. Мне любопытно, что мне не хватает.

Я заметил, что автоматически сгенерированный код родинок объявил необходимые атрибуты MoledAssembly. Но в моих тестах тестовый проект, похоже, должен объявить это свойство; он не может быть объявлен в проекте сборкой, на которую указывает ссылка. Однако в случае с автоматически сгенерированной сборкой, ПОЯВЛЯЕТСЯ, что атрибут может быть объявлен «снаружи». Это мое предположение, основанное на том, что я могу увидеть при разборке автоматически сгенерированной библиотеки moles dll; Другой разницы не могу найти. Однако, как я пытаюсь объяснить, копирование всего кода (и атрибутов) из дизассемблированной автоматически сгенерированной библиотеки moles dll и создание моей собственной сборки, на которую ссылаются, не удается во время выполнения, говоря, что я не пометил необходимую сборку в тесте для инструментирования (т.е. помечены MoledAssembly) - хотя он есть, просто в моей упомянутой сборке.

- update

На этом этапе (вероятно, из-за моего непонимания того, что отсутствует в моем коде), я считаю, что мы должны быть очень конкретными в отношении какая сборка какая есть. Допустим, у нас есть 4 библиотеки DLL:

  1. Test.dll: проект mstest. Не объявляется MoledAssembly .
  2. Moles.dll: автоматически сгенерированная dll, созданная при использовании файла *. Moles в вашем проекте. Ссылается на 4-ю dll (см. №4) Sealed . Объявляет [сборка: MoledAssembly ("Герметичный")] . Обратите внимание, что я пытаюсь выполнить ручную инъекцию кротов без этой dll - это всего лишь концептуальная ссылка или для использования в нашем обсуждении или устранении неполадок.
  3. MyMoles.dll: Моя скомпилированная из исходного кода версия автоматически сгенерированной Moles .dll .
  4. Sealed.dll: Содержит тестируемый код.

В ответах / комментариях / вопросах - давайте ссылаться на каждую часть в соответствии с этим списком.

6
задан payo 8 June 2011 в 17:01
поделиться