Код модульного тестирования с зависимостью файловой системы

Я сдержан для загрязнения моего кода типами и понятиями, которые существуют только для упрощения поблочного тестирования. Несомненно, если это делает инструмент для очистки дизайна и лучше затем большой, но я думаю, что это часто - не случай.

Мое взятие на этом - то, что Ваши модульные тесты сделали бы столько, сколько они могут, который не может быть 100%-м покрытием. На самом деле это могут только быть 10%. Точка, Ваши модульные тесты должны быть быстрыми и не иметь никаких внешних зависимостей. Они могли бы протестировать случаи как "этот метод броски ArgumentNullException, когда Вы передаете в пустом указателе для этого параметра".

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

При измерении покрытия кода, я измеряю и модульные и интеграционные тесты.

Нет ничего неправильно с ударом файловой системы, просто считайте это интеграционным тестом, а не модульным тестом. Я подкачал бы твердый кодированный путь с относительным путем и создал бы подпапку TestData для содержания zip для модульных тестов.

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

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

Один путь состоял бы в том, чтобы записать разархивировать метод для взятия InputStreams. Затем модульный тест мог создать такой InputStream из использования массива байтов ByteArrayInputStream. Содержание того массива байтов могло быть константой в коде модульного теста.

Это, кажется, больше интеграционного теста, как Вы в зависимости от определенной детали (файловая система), который мог измениться в теории.

я абстрагировал бы код, который имеет дело с ОС в свой собственный модуль (класс, блок, банка, безотносительно). В Вашем случае Вы хотите загрузить определенный DLL, если найдено, поэтому сделайте интерфейс IDllLoader и класс DllLoader. Имейте свое приложение, получают DLL от DllLoader с помощью интерфейса и теста это.. Вы не ответственны за разархивировать код afterall право?

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

Вы не должны тестировать взаимодействие класса и функциональный вызов. вместо этого необходимо рассмотреть интеграционное тестирование. Протестируйте необходимый результат а не операцию загрузки файла.

Для модульного теста я предложил бы, чтобы Вы включали тестовый файл в свой проект (файл EAR, или эквивалентный) затем используют относительный путь в модульных тестах т.е. "../testdata/testfile".

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

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

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