Блог

Итак, я сталкиваюсь с проблемой, когда я приступаю к сборке своих проектов с использованием контроллера сборки tfs, используя местоположение вывода «asconfigured», он не обнаружит мои модульные тесты. Позвольте мне дать немного информации о моей настройке.

Обновление TFS 2013 2, шаблон процесса по умолчанию

Вот несколько скриншотов, которые, надеюсь, помогут заполнить то, что я не могу набрать. Я копирую свою сборку в общий файловый ресурс в нашей сети, чтобы мы могли использовать другие утилиты, использующие выходные данные. Я не хочу использовать «PerProject» или «SingleFolder», потому что они портят файловую структуру, которую мы настроили (они оба будут запускать тесты). Итак, у меня есть файлы, копируемые в имена папок «SingleOutputFolder», которые являются дочерними элементами DropLocation. Я хотел бы иметь возможность запускать из папки drop или запускать из папки bin для каждого из моих тестов (мне все равно, какой). Однако, похоже, он не обнаруживает / не запускает НИ ОДИН из тестов. Любая помощь будет принята с благодарностью. Пожалуйста, дайте мне знать, если вам нужна дополнительная информация.

Я пробовал использовать *** test * .dll, InstallSingleFolderOutput ** .test.dll , и $(TF_BUILD_DROPLOCATION)InstallSingleFolderOutput*тест*.dll

Но я не уверен, какие переменные доступны, и понимаю, где область его выполнения.

Учитывая, что вы используете местоположение вывода сборки, установленное на AsConfigured, вам необходимо изменить значения по умолчанию для настройки спецификации Test sources, чтобы разрешить сборке находить тестовые библиотеки в папках bin. Вот пример.

Если полный путь к библиотекам модульного тестирования:

 E:Builds7<TFS Team Project><Build Definition>src<Unit Test Project>binRelease*test*.dll
  

используйте

 ..src*UnitTest*bin**test*.dll;
  

Этот вопрос был задан на форумах MSDN здесь.

Форумы MSDN предложили обходной путь

Предлагаемый обходной путь в принятом ответе (по состоянию на 8 часов утра 20 июня) заключается в указании полного пути к двоичным папкам тестовых проектов: например:

 C:Builds{agentId}{teamProjectName}{buildDefinitionName}src{solutionName}{testProjectName}bin*Debug*test*.dll*
  

что действительно должно было быть показано как

 {agentWorkingFolder}src{relativePathToTestProjectBinariesFolder}*test*.dll
  

Однако этот подход очень хрупкий по следующим причинам:

1. Любые новые тестовые проекты, которые вы добавляете в решение, не будут выполняться, пока вы не добавите их в список тестовых источников определения сборки:
2. Он сломается при любом из следующих обстоятельств:
   • определение сборки переименовано
   • рабочая папка в свойствах агента сборки изменена
   • у вас есть несколько агентов сборки, и сборку выполняет агент, отличный от того, который вы указали в {id}

Улучшено обходное решение

Мой обходной путь устраняет проблемы, перечисленные в # 2 (ничего не могу поделать с # 1).

В указанном выше пути замените начальную часть:

 {agentWorkingFolder} 
  

с

 ..
  

итак, у вас есть

 ..src{relativePathToTestProjectBinariesFolder}*test*.dll
  

Это работает, потому что внутренним рабочим каталогом, по-видимому, является binaries folder, который является родственным src folder . Переход к родительской папке (как бы она ни называлась, нам все равно) и обратно в src перед указанием пути к двоичным файлам тестовых проектов делает свое дело.

Примечание: Если у вас несколько тестовых проектов, вы добавляете дополнительные записи, разделенные точками с запятой:

 ..src{relativePathToTestProjectONEBinariesFolder}*test*.dll;..src{relativePathToTestProjectTWOBinariesFolder}*test*.dll;..src{relativePathToTestProjectTHREEBinariesFolder}*test*.dll;
  

В итоге я добавил событие post build для копирования всего теста.dll в папку промежуточного расположения в конкретной сборке, которая в основном эквивалентна тому, куда она будет отправляться при сборке с одной папкой, и делать это в каждом тестовом проекте.

 if "$(TeamBuildOutDir)" == "" (
echo "Building Interactively not in TFS"
) else (
echo "Building in TFS"
xcopy "$(TargetDir)*.*" "$(TeamBuildBinaries)" /Y /E /S
)
  

Параметр MSBUILD в build def, который сообщил ему, что он в основном попадает в папку, в которой их ищет TFS.

 /p:TeamBuildBinaries="$(TF_BUILD_BINARIESDIRECTORY)"
  

Сохранена спецификация файла тестовой сборки по умолчанию:

 ***test*.dll
  

Просмотрите эту ссылку для получения информации о переменной, которую я использовал, и о том, какой относительный путь она существует.

Другое решение — сделать обратное.

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

Вместо этого используйте сценарий предварительного удаления powershell для создания вашей схемы установки из корневых файлов.

Если это приложение, вы можете использовать пакет Nuget _ApplicationFolder для создания папки _PublishApplications, такой же, как для веб-приложений.