2016-04-28 3 views
5

В настоящее время мы переносим наши модульные тесты с использованием MSTest на NUnit (версия 3.2.1), но возникают проблемы с запуском тестов NUnit из нашего определения сборки TFS .xaml. В определении сборки TFS используется правило «Запускать тесты в сборках, соответствующих ** \ *. Test * .dll». Для моего тестового проекта NUnit я скачал, установил и ссылки на следующий NuGet пакетов:Тесты NUnit3 не запускаются на сборке TFS

1) NUnit v3.2.1

2) NUnit3TestAdapter v3.0.10

-исполнители моих тестов в VS (тест исследователь) работает отлично, и я думал, что этих шагов будет достаточно, чтобы гарантировать, что они также выполняются как часть сборки CI на TFS, однако тесты никогда не выполняются. У меня нет ошибок/предупреждений/сообщений, относящихся к этим тестам, на диагностическом выходе, однако я вижу, что процесс сборки обнаружил мою сборку в качестве кандидата для модульных тестов, поскольку он соответствует вышеупомянутому шаблону (** \ *. Test * .dll).

Я также попытался поместить сборки NUnit3TestAdapter в папку «Контрольный путь версии к пользовательским сборкам», определенный в свойствах контроллера сборки для TFS, но безрезультатно.

Может ли кто-нибудь увидеть, не хватает ли здесь шага в этом процессе. Из всего, что я прочитал на этих форумах, я, кажется, сделал все необходимое, но они все равно не исполняются.

Я очень упростил эту проблему, просто выполнив MSTest, exe (именно это использует сборка TFS) непосредственно на сборке, содержащей мои тесты NUnit. Соответствующая сборка имеет как адаптеры, так и nunit-рамки, установленные как пакеты NuGet, и все же MsTest сообщает, что тесты не найдены (см. Ниже):

C: \ Users \ hdav> "C: \ Program Files (x86) \ Microsoft Visual Studio 14.0 \ Common7 \ IDE \ MSTest.exe»/testcontainer:e:\MyCode\nunit\ExpectedExceptionExample\bin\Debug\ExpectedExceptionExample.dll

Загрузка е: \ MyCode \ NUnit \ ExpectedExceptionExample \ Bin \ Debug \ ExpectedExceptionExample.dll ...

Начиная исполнение ...

нет тестов для выполнения.

+0

Не могли бы вы поделиться своим журналом сборки? Вы можете видеть, как TestAdapter восстановлен во время сборки? –

+0

Я не могу поделиться с вами журналом сборки, но не могли бы вы рассказать о том, что вы имеете в виду, увидев, что TestAdapter «восстановлен»? Я предполагаю, что вы имеете в виду NUnit3.TestAdapter.dll, если да, то да, я вижу следующую строку в журнале построения: «Добавление сопоставления из« $/TFSAdministration/BuildProcessTemplates/CustomAssemblies/NUnit3.TestAdapter.dll »в .... .. " – davies

+0

При выполнении тестов с использованием' MsTest' будут выполняться только проекты старого стиля MsTest. Чтобы загрузить новый расширяемый тестовый бегун, вы * должны * выполнить 'vstest.console.exe' вместо этого. – jessehouwing

ответ

0

Я столкнулся с той же проблемой и обнаружил, что файлы для тестовых проектов должны присутствовать в файле pbd, чтобы адаптер мог обнаружить тесты.

В то время как файлы .pbd генерировались локально, сборка (в данном случае TF Build) поставляла переключатель /p:DebugType=None аргументам MSBuild. Удаление коммутатора позволило обнаружить тесты и запустить их в сборке. Не могли бы вы иметь что-то подобное в определении сборки?

Вопрос принят в качестве bug на GitHub.