Unit-тестирование работы с файловой системой

#юнит_тесты #тестирование #test_driven_development

Возможно ли unit-тестирование класса, основная задача которого состоит во взаимодействии
с файловой системой? Ну например, мне нужно протестировать класс, который предоставляет
возможность записывать/читать биты из файла. Каким образом я могу это сделать? Можно,
конечно, записать файл с какими-то тестовыми данными, а в самом тесте проверять что
считываются именно те данные. Мне это кажется каким-то костылем. Так ли это и какие
есть еще способы протестировать работу такого класса?
    

Ответы

Ответ 1

Давайте попробуем пройтись по задачке в стиле TDD:


Какие публичные методы должен иметь данный класс? Пусть это будет только чтение Read(path,
offset, count) и запись Write(name, offset, count).
Пока мы не пишем их код, пока нам надо придумать, как бы мы их могли  протестировать?
Напишем несколько тестов (которые, кстати, помогут нам более точно описать поведение
и интерфейс класса):  


Прочитать что-то из файла и проверить, что прочиталось именно то что надо.
Что должно произойти, если отдана команда прочитать 100 байт из файла размером 50
байт? Вернуть 50 байт, вернуть ошибку/исключение, или вернуть 100 байт из которых последние
50 - пустые? Выбирайте вариант и пишите на него тест.
Что должно произойти, если файл не существует или недоступен? Опять же, выбирайте
"правильное" поведение и пишите на него тест.
Разрешаем ли мы передавать отрицательное значение offset, и что оно будет означать
(например чтение с конца, а не с начала). Пишем тест.
Будем ли мы поддерживать чтение/запись по локальной сети? Длинные имена файлов (260+)?
Запись в системные папки (с требованием админских прав)?
Что еще должно работать и что может пойти не так .. продумайте желаемое поведение
и напишите на него тесты.


Повторите то же для метода записи в файл. Не стремитесь сразу предусмотреть ВСЁ.
Учитывайте только то что вам понадобится в обозримом будущем (согласно вашему ТЗ).
Теперь можно сделать паузу, и обобщить все те моменты и тонкости которые всплыли
при проектировании тестов. Окинуть их взглядом еще раз, прикинуть какие ситуации требуют
приватных методов и функций, общих для чтения и записи (например, проверка существования
файла, или размера).
А вот только теперь можно приступать к написанию кода самого класса чтения/записи в файл!
Встретили какое-то еще условие, или граничный случай в процессе разработки - отлично,
напишите на него тест, а потом код.
В процессе эксплуатации класса выявился баг - тоже отлично, пишите на него тест,
и только потом исправляйте баг (и тестом проверяйте, что он исправлен, и что в процессе
исправления ничего из другого не сломалось).