модульное тестирование, рефакторинг, IO

Question

У вас есть метод в классе, который имеет 2 параметра, один из которых является путем к файлу, а другой не имеет значения.

InterestingResult result = foo.Bar(irrelevant, filePathInfo);

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

string dataInFile = foo.GetDataInFile(filePathInfo);
InterestingResult result = foo.Bar(irrelevant, dataInFile);

Ты с ума сошел? ... или это было хорошо?

Answer 1

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

Answer 2

Самое простое, что работает.

• Для теста предоставьте золотой файл (только для чтения), для которого вы знаете ожидаемый результат (сохраните его в Test / Resources). Если это достаточно быстро, нет необходимости менять производственный код.
• Если тест, попадающий в FileSystem, невыносимо медленен (что-то более полсекунды), абстрагируйте FileSystem Access (используйте Mock / Fake) (что-то похожее на второй фрагмент вашего вопроса).

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

Answer 3

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

Answer 4

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

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

Answer 5

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