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

Один из способов - написать метод unzip для приема InputStreams. Затем модульный тест может построить такой InputStream из массива байтов с помощью ByteArrayInputStream. Содержимое этого байтового массива может быть константой в коде модульного теста.

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

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

Я считаю, что ваши модульные тесты будут делать все, что в их силах, что может не обеспечивать 100% покрытие. Фактически, это может быть всего 10%. Дело в том, что ваши модульные тесты должны быть быстрыми и не иметь внешних зависимостей. Они могут проверять такие случаи, как «этот метод вызывает исключение ArgumentNullException, когда вы передаете значение null для этого параметра».

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

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

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

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

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

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

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

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

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

Также было бы неплохо поместить chdir() во временный каталог перед запуском теста, а затем обратно chdir().

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

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

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

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

Yay! Now it's testable; I can feed in test doubles (mocks) to the DoIt method. But at what cost? I've now had to define 3 new interfaces just to make this testable. And what, exactly, am I testing? I'm testing that my DoIt function properly interacts with its dependencies. It doesn't test that the zip file was unzipped properly, etc.

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

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

"Что, черт возьми, я тестирую?"

Ваш пример не очень интересен, потому что он просто склеивает некоторые вызовы API вместе, поэтому, если бы вы написали для него модульный тест, вы бы просто утверждали, что методы были вызваны. Подобные тесты тесно связывают детали вашей реализации с тестом. Это плохо, потому что теперь вам нужно менять тест каждый раз, когда вы меняете детали реализации вашего метода, потому что изменение деталей реализации нарушает ваш тест (ы)!

Плохие тесты на самом деле хуже, чем их полное отсутствие.

В вашем примере:

void DoIt(IZipper zipper, IFileSystem fileSystem, IDllRunner runner)
{
   string path = zipper.Unzip(theZipFile);
   IFakeFile file = fileSystem.Open(path);
   runner.Run(file);
}

Хотя вы можете передавать макеты, в методе тестирования нет логики. Если бы вы попытались выполнить модульный тест для этого, это могло бы выглядеть примерно так:

// Assuming that zipper, fileSystem, and runner are mocks
void testDoIt()
{
  // mock behavior of the mock objects
  when(zipper.Unzip(any(File.class)).thenReturn("some path");
  when(fileSystem.Open("some path")).thenReturn(mock(IFakeFile.class));

  // run the test
  someObject.DoIt(zipper, fileSystem, runner);

  // verify things were called
  verify(zipper).Unzip(any(File.class));
  verify(fileSystem).Open("some path"));
  verify(runner).Run(file);
}

Поздравляем, вы в основном скопировали детали реализации вашего метода DoIt() в тест. Счастливого сохранения.

Когда вы пишете тесты, вы хотите тестировать КАКИЕ, а не КАК. Подробнее см. Тестирование черного ящика.

КАКИЕ - это имя вашего метода (или, по крайней мере, должно быть). КАК - это все маленькие детали реализации, которые живут внутри вашего метода. Хорошие тесты позволяют заменить КАК, не нарушая КАКИЕ.

Подумайте об этом так, спросите себя:

«Если я изменю детали реализации этого метода (без изменения публичного контракта), нарушат ли мои тесты?»

Если ответ положительный, вы тестируете КАК, а не КАКИЕ.

Чтобы ответить на ваш конкретный вопрос о тестировании кода с зависимостями файловой системы, предположим, что у вас происходит что-то более интересное с файлом, и вы хотите сохранить закодированное в Base64 содержимое byte[] в файл. Вы можете использовать для этого потоки, чтобы проверить, что ваш код работает правильно, без необходимости проверять, что как это делает. Одним из примеров может быть что-то вроде этого (на Java):

interface StreamFactory {
    OutputStream outStream();
    InputStream inStream();
}

class Base64FileWriter {
    public void write(byte[] contents, StreamFactory streamFactory) {
        OutputStream outputStream = streamFactory.outStream();
        outputStream.write(Base64.encodeBase64(contents));
    }
}

@Test
public void save_shouldBase64EncodeContents() {
    OutputStream outputStream = new ByteArrayOutputStream();
    StreamFactory streamFactory = mock(StreamFactory.class);
    when(streamFactory.outStream()).thenReturn(outputStream);

    // Run the method under test
    Base64FileWriter fileWriter = new Base64FileWriter();
    fileWriter.write("Man".getBytes(), streamFactory);

    // Assert we saved the base64 encoded contents
    assertThat(outputStream.toString()).isEqualTo("TWFu");
}

В тесте используется ByteArrayOutputStream, но в приложении (с использованием внедрения зависимостей) реальный StreamFactory (возможно, называемый FileStreamFactory) вернет FileOutputStream из outputStream() и будет писать в File.

Что было интересно в методе write, так это то, что он записывал содержимое в кодировке Base64, поэтому мы и тестировали именно это. Для вашего метода DoIt() это было бы более уместно протестировать с помощью интеграционный тест.