Передано как ответ и уточнено.
Тот факт, что вы запускаете код модульного тестирования, который не выполняется из-за ненадежного расположения, является признаком того, что вы не проводите модульное тестирование, вы проводите интеграционное тестирование. Это хрупко и склонно к другим проблемам, поэтому я постараюсь избегать этого в максимально возможной степени.
Юнит-тестирование должно проверять небольшие кусочки логики, единицы кода, такие как классы, методы и т. Д.
Когда вы извлекаете код, выполняющий одно из следующих действий, у вас могут возникнуть проблемы:
- Код, который требует базы данных
- Код, который требует файл (или доступ к файлу)
- Код, который взаимодействует с какой-либо внешней системой (например, COM-объектом, веб-службой, чем-либо по сети)
Например, что произойдет, если:
- Вы запускаете модульные тесты на своей машине, но дома? У вас есть доступ к тем же системам?
- База данных изменяется?
- База данных перемещена на другой сервер, чтобы освободить место?
- Диск заполнен?
- Сеть не работает или происходит сбой?
Все эти и многие другие вещи приведут к сбою ваших модульных тестов, потому что вы не только тестируете логику, которая находится на другом конце этих путей соединения, но также проверяете, работает ли путь соединения .
Это делает ваши тесты хрупкими и подверженными ошибкам.
Когда тест не пройден, вы всегда захотите сказать: «Хорошо, мы должны что-то сделать, чтобы сломать код». Вам никогда не захочется слышать это «аааа, этот тест все время не проходит, просто оставьте его, возможно, это снова сервер».
Причина, по которой ваши модульные тесты не пройдены, связана с вашим вопросом, потому что код необходим для связи с внешней системой (файл, база данных, веб-сервер, сетевое устройство), поэтому требуется повышенное доверие. Если он запускает только нормальный код, он не требует повышенного доверия, поэтому ваша проблема - пустая расплата за такие тесты.
Эти тесты называются интеграционными тестами, потому что они не только тестируют код, но и проверяют, насколько хорошо ваш код интегрируется с внешним миром.
Я бы попытался удалить эти части теста, возможно, путем их рефакторинга, чтобы вы могли заменить их тестовыми системами в своих модульных тестах.
Например:
- Если ваш код должен записывать в файл, выделите код для записи в файл в новый класс, используя метод, подобный
WriteToFile, оберните класс в интерфейсе и передайте объект логическому коду в качестве параметра. Затем в своих модульных тестах создайте новый класс, реализующий тот же интерфейс, но он просто записывает, что метод был вызван, и не пытайтесь записать что-либо в файл. Таким образом, вы можете проверить, что «метод, который должен был записать в файл, действительно вызывался с правильными данными», а не «файл был успешно записан».
Для серверов баз данных и веб-серверов и аналогичных программ вы можете сделать то же самое.
Наконец, обратите внимание, что в какой-то момент вы, возможно, захотите запустить тесты, которые гарантируют, что файл действительно окажется на диске. Однако вы должны выделить все эти тесты в их собственный проект, чтобы в случае их поломки вы знали, что это интеграционный тест, и все модульные тесты могли нормально работать.