Тестовые проекты не читают app.config в TeamCity -> фаза NUnit

Question

Что ж, мы сталкиваемся со странной проблемой с модульными тестами, вызванными JetBrains TeamCity, в нашем основном проекте, когда тесты из нескольких библиотечных проектов регулярно дают сбой.По-видимому, он не читает конфигурационный файл (полученный из app.config и хорошо хранящийся в проекте -> bin -> debug -> projectName.dll.config).

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

Answer 1

У меня та же проблема, и я потратил пару часов, чтобы выяснить, в чем проблема.

В нашем случае плагин NUnit был настроен для запуска тестов с:

**\*Tests.dll

Хотя это звучит нормально, оказалось, что этот шаблон будет соответствовать не только MyTests.dll в папке bin \ Debug, но и obj \ Debug \ MyTests.dll.Папка obj используется для компиляции внутри и не содержит файл конфигурации.

Наконец, решение состояло в том, чтобы изменить конфигурацию плагина на

**\bin\Debug\*Tests.dll

На самом деле мы используем системную переменную длясобрать конфигурацию, чтобы у нас не было жестко запрограммированного «Debug».Использование bin * может быть также опасным, когда рабочая область также используется для сборок Debug / Release, и вы не указали полную очистку.

Вы можете удивиться, почему я не осознал несоответствие количества тестов (на самом деле этобыл удвоен, потому что они запускались один раз из bin и один раз из obj), но это типично: пока все зеленое, вам все равно количество.Когда мы ввели первый тест в зависимости от конфигурации, у нас был только один сбой (потому что проходил тест из bin), поэтому дублирование не было выдающимся.

Answer 2

Помимо принятого Гаспаром Надя ответа , проверьте, есть ли в вашем проекте несколько тестовых библиотек, и один из них ссылается на другой.

Это приводит к тому, что указанная dll запускается дважды, а копия, находящаяся в папке другой dll, не имеет надлежащих записей app.config.Надлежащее решение - удалить все ссылки из другого тестового проекта.

Answer 3

TeamCity (v6.5.4) имеет свой собственный NUnit Test Runner, и, кажется, существует несоответствие между ним и NUnit GUI Test Runner (2.5.10).Средство NUnit GUI Test Runner следует давним правилам, согласно которым имя файла конфигурации должно иметь формат .config.Вы можете увидеть это в NUnit, посмотрев на Project -> Edit ...

TeamCity с другой стороны ищет app.config.

Вы можете выбрать один из следующих вариантов:

1. Установите графический интерфейс NUnit так, чтобы он указывал на app.config, и включите получившийся проект nunit в систему управления версиями.
2. Иметь app.config и .config - синхронизация вручную.
3. Добавьте шаг в процесс сборки, чтобы скопировать .config в app.config (или наоборот).

Answer 4

У меня были похожие проблемы

Это может помочь;Кроме того, у нас были проблемы, из-за которых это все еще не работало - мы закончили копированием соответствующих разделов конфигурации в файл конфигурации самого высокого уровня.(т. е. если это было веб-приложение, скопируйте его в Web.Config) - довольно глупо, но мы потратили несколько дней на решение проблемы

Answer 5

Если вам нужен файл конфигурации для ваших «модульных» тестов, значит, вы делаете это неправильно. Правильное модульное тестирование никогда не требует настройки или доступа к базе данных, файловой системе и т. Д. Вам следует изменить свою стратегию тестирования.

Хорошее начало - пометьте свои тесты, нуждающиеся в настройке, аннотацией [Category("Integration")] и заставьте тестировщика Teamcity игнорировать эту категорию. Тогда вы должны сосредоточиться на рефакторинге этих тестов.

Answer 6

Недавно я узнал, что файлы app.config не читаются для библиотеки классов ... Может быть, эта ссылка может помочь:)

app.config для библиотеки классов