Модульный тест Visual Studio - странное поведение

Question

Кто-нибудь видел такое очень странное поведение раньше?

1. У меня есть решение с 70 юнит-тестами.Все они проходят на моем компьютере разработчика.
2. Всякий раз, когда я фиксирую свои изменения, начинается процесс непрерывной интеграции, и сборочная коробка в конечном итоге запускает те же 70 модульных тестов.
3. Существует только ОДИНtest в окне сборки, который все время терпит неудачу.
4. Ошибка находится в одной строке, которая получает запись только из нашей базы данных модульного теста.(Я знаю, что отстойно иметь модульный тест, чтобы полагаться на данные, но, пожалуйста, не зацикливайтесь на этом, так как это сейчас не актуально)
5. Самое странное, когда я регистрируюсь в окне сборки, открываюРешение Visual Studio и вручную запустить модульные тесты.Результат: ALL PASS!

Кто-нибудь когда-нибудь сталкивался с такой странной ситуацией?Я предполагаю, что с Cruise Control.NET и MSTest происходит что-то странное?

Answer 1

Конечно, ваш юнит-тестировщик выдает хороший журнал, который показывает точное сообщение об ошибке или ошибку?Гадать на этом бессмысленно, но ошибка типа «отказ в доступе» была бы очевидным кандидатом.Настройте любой движок dbase, который вы используете (вы тоже забыли об этом упомянуть), чтобы предоставить учетной записи пользователя, которая запускает тесты, доступ к таблицам.

Answer 2

Если у вас есть системные тесты, которые вы хотите запустить на своем сервере сборки или вообще, хотите иметь возможность корректно запускаться на любом компьютере, включая ваш, то вы должны убедиться, что их состояния независимы.

В вашем случае каждый тестовый инициатор должен подготовить используемую БД (либо путем копирования файловой БД, либо путем опустошения / заполнения БД на основе служб). Каждый тест должен также попытаться отменить свои изменения (удалить файл или пустую БД), но не предполагать, что другие тесты прошли успешно.

Answer 3

спасибо за ваш вклад, но это никак не связано с учетными данными. Я обнаружил, что другие тесты, которые выполнялись до этого, оставляли мою базу данных модульных тестов в несогласованном состоянии, что приводило к ошибкам рассматриваемого теста. Не рекомендуется, чтобы ваши модульные тесты опирались на данные, поэтому, если вы не очень привязаны к ним, как я, это то, что всем рекомендуется: НЕ ПОЛЬЗУЙТЕСЬ ДАННЫМИ, ЧТОБЫ ПРОВЕРИТЬ СВОЙ БЛОК !!!! Убедитесь, что у вас есть все хорошие вещи, в частности, хороший контейнер IOC / инжектора зависимостей, чтобы ваши классы были слабо связаны, и вы можете смоделировать любой интерфейс, который вам может понадобиться для модульного тестирования!

Answer 4

Как сказано в другом ответе, не имеет особого смысла догадываться об этом, когда вокруг подробные журналы ...

Но поскольку у меня была такая ситуация несколько раз, в любом случае, вот предположение: Учетная запись, которая используется сервером CI для запуска тестов, может не иметь соответствующих разрешений в базе данных. Это также объясняет, почему тот же тест завершается успешно, когда вы запускаете его вручную (затем с учетной записью пользователя) ...

НТН! Томас