Тестирование проектов, не читающих app.config в TeamCity → Фаза NUnit

Ответ 1

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

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

**\*Tests.dll

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

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

**\bin\Debug\*Tests.dll

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

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

Ответ 2

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

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

Ответ 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.

Ваши варианты:

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

Ответ 4

У меня были подобные беды

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

Ответ 5

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

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

Ответ 6

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

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