Атрибут сборки требуется при использовании смоделированных сборок, которые не создаются автоматически. Инструменты Moles для Visual Studio автоматически предупреждают компилятор о наличии сгенерированных сборок по необходимости.
При добавлении сборки кротов через Visual Studio сборка кротов не создается до тех пор, пока не будет построен проект. Кроме того, невозможно включить атрибут сборки для сборки, которая еще не существует. Это приведет к сбою компилятора. Следовательно, Moles также необходимо динамически добавлять команды в командную строку компилятора, генерировать смоделированные сборки и затем правильно ссылаться на них из проекта.
При использовании сгенерированной вручную сборочной сборки необходимо включить атрибут сборки, поскольку инструментам Moles не известно о его наличии, поскольку сборка не создается автоматически. Программист должен выполнить работу для родинок.
Если вы хотите пойти дальше, вы можете использовать генерацию кода до того, как компилятор включится. PERL может легко ввести необходимый атрибут сборки, где это необходимо. Когда компилятор получит код, ему уже будут вставлены атрибуты.
Эксперимент в поддержку моего ответа:
Мне удалось воспроизвести вашу проблему. Я также смог решить проблему, добавив атрибут сборки ниже , используя блок операторов . Для создания примера приложения я предпринял следующие шаги:
- Создан проект библиотеки классов .NET 4.0 C # с именем ClassLibrary2.
Создан следующий метод, в Class1:
публичная строка TestString () {return "Original value."; }
Создал тестовый проект (TestProject1), щелкнув правой кнопкой мыши объявление метода TestString и выбрав Создать модульные тесты ... (Ленивый, я знаю.)
- Удалил лишнее дерьмо из Class1Test.cs, оставив TestStringTest ().
- Добавлена сборка родинок для mscorlib. (Еще один ленивый ярлык и ненужный шаг, оглядываясь назад. Я отмечаю это здесь, потому что это то, что я сделал.)
- Добавлена сборка родинок для ClassLibrary2.
- Скомпилированное решение с использованием профиля по умолчанию Любой профиль CPU .
- Использовал Redgate (извините, @payo) для декомпиляции ClassLibrary2.Moles
- Добавлен новый проект библиотеки классов с именем MoleClassLibrary.
- Скопировал декомпилированный код MClass1 и SClass1 в MoleClassLibrary.
- Удален файл Class1.moles и сборки из TestProject1.
- Удалил (ненужный) файл mscorlib.moles и сборки из TestProject1.
- Добавлена ссылка MoleClassLibrary на TestProject1.
- Обновлен с использованием оператора в Class1Test.cs.
- Построить решение.
- Выполнено TestStringTest () с использованием Visual Studio 2010 Тестовое представление окно .
- Тест не пройден, подробности:
метод испытания
TestProject1.Class1Test.TestStringTest
бросил исключение:
Microsoft.Moles.Framework.Moles.MoleNotInstrumentedException:
System.String
ClassLibrary1.Class1.TestString () был
не инструментировано Чтобы решить эту проблему
вопрос, добавьте следующий атрибут в
тестовый проект:
с использованием Microsoft.Moles.Framework;
[Сборка:
MoledAssembly (TypeOf (ClassLibrary1.Class1))]
Я добавил рекомендованный атрибут сборки в файл. После этого метод испытания прошел успешно. Я подозреваю, что компилятор автоматически ссылается на сгенерированные смоделированные сборки, устраняя необходимость в атрибуте сборки. Я попытался скопировать двоичные файлы MoleClassLibrary в каталог MolesAssemblies и создать файл MoleClassLibrary.moles, чтобы проверить эту теорию. Тест прошел только тогда, когда я включил атрибут сборки. Этот результат не соответствует моей гипотезе.
Вот код для Class1Test.cs:
using ClassLibrary1;
using Microsoft.Moles.Framework;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using MoleClassLibrary;
[assembly: MoledAssembly(typeof(ClassLibrary1.Class1))]
namespace TestProject1
{
[TestClass()]
public class Class1Test
{
[TestMethod()]
[HostType("Moles")]
public void TestStringTest()
{
var target = new Class1();
var expected = "Mole value.";
string actual;
MClass1.AllInstances.TestString = value => expected;
actual = target.TestString();
Assert.AreEqual(expected, actual);
}
}
}