Испытание модуля Visual Studio - странное поведение

Question

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

HTH! Thomas

Answer 4

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

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