Проблемы с атрибутом DeploymentItem

В настоящее время я поддерживаю "старую" систему, написанную на С#.net, удаляя некоторые устаревшие функции и делая некоторые рефакторинг. Слава богу, предыдущий парень написал несколько модульных тестов (MSTests). Мне очень нравятся тесты JUnit, но с MSTests он еще ничего не сделал.

Методы тестирования имеют атрибут DeploymentItem, определяющий текстовый файл, который анализируется тестируемым бизнес-логическим методом, и второй DeploymentItem, где указан только путь, содержащий кучу файлов TIF, которые имеют для развертывания тоже.

[TestMethod()]
[DeploymentItem(@"files\valid\valid_entries.txt")]
[DeploymentItem(@"files\tif\")]
public void ExistsTifTest()
{
   ...
}

Тесты работали до этого, но теперь мне пришлось изменить имена файлов TIF, содержащихся в каталоге \files\tif. Согласно правилу, имена файлов TIF должны соответствовать определенному шаблону, который также проверяется методом ExistsTifTest(). Теперь мне пришлось изменить имена файлов, чтобы адаптировать их к новым требованиям и, как ни странно, файлы TIF больше не развертываются по-прежнему.

Может кто-нибудь дать мне подсказку, почему это происходит или что может быть причиной? То же самое происходит и при добавлении нового текстового файла "my2ndTest.txt" рядом с "valid_entries.txt" в каталоге\files\valid\с соответствующим атрибутом DeploymentItem в методе тестирования. Файл не развернут?

Я получил развернутые изображения, определяя путь развертывания непосредственно в testrunconfig, но я хотел бы понять, почему это происходит или почему, например, мой новый файл "my2ndTest.txt" не развертывается, а остальные сделать.

Ответ 1

DeploymentItem - это немного беспорядок.

Каждый файл в вашем решении будет иметь настройку "Копировать в выходную папку" в VS.NET. Вам нужно, чтобы это было "Копировать всегда" (или подобное), чтобы получить файлы в выходной папке.

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

Лично, если у меня есть файлы, которые мне нужны для моих модульных тестов, я обнаружил, что вложение этих файлов в качестве ресурсов в сборку, а сама сборка "распаковать" сама во время тестов - более предсказуемый способ делать что-то. YMMV.

Примечание: Эти комментарии основаны на моем опыте с VS2010. Комментарии к моему ответу предполагают, что это не проблема с VS2012. Я по-прежнему придерживаюсь комментариев о том, что использование встроенных ресурсов включает в себя меньше "магии" и, для меня, значительно упрощает "этап" моих модульных тестов.

Ответ 2

В VS2010 мои настройки Local.tests установили флажок "Включить развертывание", а атрибут DeploymentItem не работал. Я проверил его, и все сработало нормально. Надеюсь, это поможет!

Ответ 3

У меня также возникли аналогичные проблемы, но я нашел легкое трехэтажное решение для этого:

Предполагая, что ваша структура папок выглядит так: SolutionFolder\ TestProjectFolder\ SubFolder\

  • Перейдите в раздел "Решения Items/Local.testsettings" > "Развертывание" > "Включить развертывание"
  • Если вы используете VS2010, убедитесь, что все файлы, которые вы хотите развернуть, имеют свойство "Скопировать в папку вывода", которое установлено в "Копировать всегда" или "Копировать, если новый"
  • Атрибут вашего TestMethod с одним из следующих:
    • [DeploymentItem(@"TestProjectFolder\SubFolder")], чтобы развернуть все содержимое <SubFolder> в каталог Test Run
    • [DeploymentItem(@"TestProjectFolder\SubFolder", "TargetFolder")] для развертывания всего содержимого <SubFolder> до <TargetFolder> в папке Test Run

Последняя заметка о MSTest (по крайней мере, для VS2010):

Если вы хотите, чтобы <TargetFolder> имел то же имя, что и <SubFolder>, использование [DeploymentItem(@"SubFolder", @"SubFolder")] будет терпеть неудачу, так как бегун MSTest попадает в глупый край. Вот почему вы должны префикс <SubFolder> с помощью <TestProjectFolder> следующим образом: [DeploymentItem(@"TestProjectFolder\SubFolder", @"SubFolder")]

Ответ 4

Мы надеемся помочь кому-то другому: я попробовал все предложения здесь и еще мой элемент развертывания не был скопирован.

Что мне нужно было сделать (как предлагалось здесь) было добавить второй параметр в атрибут DeploymentItem:

[DeploymentItem(@"UnitTestData\TestData.xml", "UnitTestData")]

Ответ 5

Если вы заходите в свой файл .testrunconfig и при развертывании снимите флажок "Включить развертывание", тесты будут выполняться в обычном расположении, и все будет работать так же, как при запуске приложения вне unit test.

Ответ 6

Это, вероятно, не относится к вашей конкретной проблеме, но вот несколько советов, которые я нашел с атрибутом [DeploymentItem].

  • Копировать в выходной каталог следует установить Копировать всегда.

Он работает НЕ, когда используется с атрибутом [TestInitialize]

[TestInitialize]
[DeploymentItem("test.xlsx")]
public void Setup()
{

Он должен быть на вашем [TestMethod], например.

    [TestInitialize]
    public void Setup()
    {
        string spreadsheet = Path.GetFullPath("test.xlsx");
        Assert.IsTrue(File.Exists(spreadsheet));
        ...
    }

    [TestMethod]
    [DeploymentItem("test.xlsx")]
    public void ExcelQuestionParser_Reads_XmlElements()
    {
        ...
    }

Ответ 7

Попробовав все другие предложения, перечисленные здесь, я все еще не мог понять, что происходит. Наконец, я обнаружил, что в меню "Тестирование/тестирование" не было файла настроек, что означает, что развертывание не было включено. Я щелкнул элемент меню "Тест/Тестирование настроек/Выбрать параметры теста", выбрал файл Local.TestSettings, затем все сработало.

Ответ 8

Не уверен, что это точно ответит на вопрос, но это может помочь некоторым. Во-первых, я обнаружил, что поле "Включить развертывание" должно быть проверено для развертывания. Во-вторых, в документе говорится, что исходный путь "относительно пути к проекту", который сначала я использовал для обозначения папки проекта. На самом деле, похоже, это относится к папке вывода сборки. Поэтому, если у меня есть папка проекта с именем "TestFiles" и файл в ней, называемый Testdata.xml, использование атрибута таким образом не работает:

[DeploymentItem(@"TestFiles\Testdata.xml")] 

Я могу пометить файл Testdata.xml Copy Always, так что сборка помещает копию под выходной папкой (например, Debug\TestFiles\TestData.xml). Механизм развертывания затем найдет копию файла, расположенного на этом пути (TestFiles\Testdata.xml) относительно вывода сборки. Или я могу установить атрибут следующим образом:

[DeploymentItem(@"..\\..\TestFiles\Testdata.xml")] 

и механизм развертывания найдет исходный файл. Таким образом, либо работает, но я заметил, что с помощью Copy Always я иногда сталкиваюсь с той же проблемой, которую я имею при редактировании файла app.config в проекте - если я не изменяю код или не перестраиваю, ничего не запускает копирование файлы, помеченные для копирования в сборке.

Ответ 9

У меня сначала был отключен флаг развертывания. Но даже после того, как я включил его, по какой-то неизвестной причине ни одна даже целевая DLL-память не будет скопирована. Случайно я открыл окно тестового прогона и убил все предыдущие прогоны, и, как ни странно, я нашел все библиотеки DLL и файлы, которые мне нужны в тестовой папке, в следующем запуске... Очень запутанно.

Ответ 10

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

Тогда я закрыл VS2010; перезагрузили его, загрузили решение и все сработало. (!)

Я сделал некоторую проверку; После установки флажка "Включить развертывание" в local.TestSetting вам не следует просто повторно запускать тест из окна результатов теста. Вы должны удалить предыдущий тестовый прогон из пользовательского интерфейса, например. путем запуска другого теста или повторного открытия вашего решения.

Ответ 11

Так как я всегда обнаружил, что атрибут DeploymentItem беспорядок, я делаю развертывание таких файлов, используя post-build script. - Убедитесь, что файлы, которые вы хотите скопировать, имеют свойство Copy Always. - Измените пост-сборку тестового проекта script, чтобы скопировать файлы из целевой папки сборки (Bin\Debug) в место, где ваш тест ожидает их.

Ответ 12

Попробуйте это для VS2010. Таким образом, вам не нужно добавлять DeployItems для каждого tif
Удалите

[DeploymentItem(@"files\valid\valid_entries.txt")]  
[DeploymentItem(@"files\tif\")]  

Добавьте тестовую конфигурацию.
 - щелкните правой кнопкой мыши по решению node в браузере решений
 - Добавить → Новый элемент...
 - Выберите Настройки тестирования node слева, выберите элемент справа
 - Нажмите Добавить

Назовите это, например, TDD

Выберите TDD в разделе TestMenu > Edit Testsettings.

Нажмите "Развертывание". Включите его, а затем добавьте файлы и каталоги, которые вы хотите. Будет путь относительно решения. Файлы будут добавлены. Например, исходный файл:

D:\Users\Patrik\Documents\Visual Studio 2010\Projects\DCArrDate\WebMVCDCArrDate\Trunk\WebMVCDCArrDate\Authority.xml  

Когда я запускаю свой unit test, он копируется в

D:\Users\Patrik\Documents\Visual Studio 2010\Projects\DCArrDate\WebMVCDCArrDate\Trunk\WebMVCDCArrDate.Tests\bin\Debug\TestResults\Patrik_HERKULES 2011-12-17 18_03_27\Authority.xml  

в тестовом коде я вызываю его из:

[TestMethod()]
public void Read_AuthorityFiles_And_ParseXML_To_Make_Dictonary()  
{  
  string authorityFile = "Authority.xml";  
  var Xmldoc = XDocument.Load(authorityFile);  

Нет необходимости выбирать Copy Always; поместите файлы в testproject; добавьте жестко заданные пути в тестовом коде. Для меня это решение работало лучше всего. Я пытался с DeploymentItem, копировать всегда, но мне это не понравилось.

Ответ 13

Я работал над этим в VS2013. Мои выводы, чтобы заставить это работать:

  • Копирование в выходной каталог должно быть установлено на Копировать, если Новее/Копировать всегда: ОБЯЗАТЕЛЬНО.
  • "Включить развертывание" в .TestSettings: НЕ ТРЕБУЕТСЯ. Я получил это работает без файла .TestSettings вообще.
  • Указание папки в качестве 2-го параметра: ДОПОЛНИТЕЛЬНО. Формирует макет выходной папки, прекрасно работает без.
  • ПРОСТРАНСТВА в имени файла: это вызвало у меня головную боль - файл никогда не копировался. Удаление пробелов исправило это. Еще не изучал побег персонажей.

Совет, который я также выучил трудным путем: не забудьте добавить этот атрибут в каждый отдельный тест. Файл копируется в первом атрибутивном тесте в testrun, но пропал без вести, когда изменился порядок тестов, и не атрибутивные тесты пытались сначала найти файл.

Ответ 14

Для тех, кто предпочитает избегать беспорядка DeploymentItem и использовать подход, предложенный @Martin Peck (принятый ответ), вы можете использовать следующий код для доступа к содержимому встроенного ресурса:

public string GetEmbeddedResource(string fullyQulifiedResourceName)
{
    var assembly = Assembly.GetExecutingAssembly();
    // NOTE resourceName is of the format "Namespace.Class.File.extension";

    using (Stream stream = assembly.GetManifestResourceStream(fullyQulifiedResourceName))
    using (StreamReader reader = new StreamReader(stream))
    {
        string result = reader.ReadToEnd();
    }
}

Подробнее см. этот SO-поток

Ответ 15

Для меня основной причиной было что-то другое: производственный код, выполняемый моими испытаниями, состоял в переименовании и/или удалении развернутого тестового файла .xml.

Поэтому, когда я буду запускать свои тесты индивидуально, они будут проходить, но при запуске их всех вместе второй и последующий тест завершится неудачей с ошибками "файл не найден" (который я первоначально неправильно диагностировал как DeploymentItem не работает).

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

Ответ 16

Мы потратили много времени на проблему с элементами развертывания, чтобы решить эту проблему в локальном unittest run и teamitity unittest reun. Это непросто.

Очень хороший инструмент для отладки этой проблемы - ProcessExplorer. Используя проводник процессов, вы можете проверить, где находится Visual Studio, для поиска элементов развертывания и внести исправления в проект. Просто отфильтруйте все операции с файлами, в которых путь содержит ваше имя файла deployitem, и вы увидите его.

Ответ 17

Помимо атрибута Deployment, который нужно проверить, я обнаружил кое-что еще об атрибуте DeploymentItem.

[TestMethod()]
[DeploymentItem("folder\subfolder\deploymentFile.txt")]
public void TestMethod1()
{
   ...
}

Ваш файл deployFile.txt должен относиться к файлу решения, а не к testfile.cs.

enter image description here

Ответ 18

Не используйте DeploymentItem.

Его очень трудно правильно настроить, и он не работал ни с моим бегунком тестов ReSharper, ни с родным для MSTEST в Visual Studio 2017.

Вместо этого щелкните правой кнопкой мыши файл данных и выберите свойства. Выберите Копировать в выходной каталог: всегда.

Теперь в вашем тесте, сделайте это. Каталог - это просто каталог файла относительно тестового проекта. Легко.

    [TestMethod()]
    public void ParseProductsTest()
    {
        // Arrange
        var file = @"Features\Products\Files\Workbook_2017.xlsx";
        var fileStream = File.Open(file, FileMode.Open);
        // etc.
    }

Похоже, это хорошо работает с автоматизированными системами сборки и тестирования.

Ответ 19

Мой большой "gotcha" был способом DeploymentItem обрабатывает каталоги. Я использовал двухпараметрическую версию с обоими как путь к каталогу, содержащий подкаталоги, которые я хотел развернуть. Первоначально я не понимал, что он копирует только материал в ROOT каталога, а не всю структуру рекурсивных папок!

В основном я имел [DeploymentItem (@ "Foo \", @ "Foo \" )] и ожидал, что он развернет мой Foo\Bar. Я специально должен был изменить его на [DeploymentItem (@ "Foo\Bar \", @ "Foo\Bar \" )], и теперь он работает как шарм.

Ответ 20

У меня также возникли аналогичные проблемы. У меня есть все шаги, упомянутые выше, но до сих пор не повезло. Я использую VS2010. Затем я обнаружил, что было выбрано $Menu > Test > Select Active Test Setting > Trace and Test impact. Он начал работать после изменения Trace и теста на Local. Эта страница содержит очень полезную информацию о копировании файлов для проверки папки результатов, я также хочу добавить этот опыт.