Обработка ввода / вывода в модульных тестах на основе TDD

Question

Я практикую основанный на Java.TDD и пишу некоторый фрагмент кода, который читает и записывает файлы. Теперь у меня есть около 100 тестов для каждого сценария (чтение и запись), чтобы проверить мой код, где я создаю файл или читаю данный файл каждый раз. Файлы для записи будут создаваться во временном каталоге и будут удаляться после каждого запуска теста. Но эта стратегия производит много ввода-вывода, и я боюсь, например, в случае. Срок службы SSD. Дразнить нельзя.

Одной из возможностей будет один раз перечитать / записать файл, а затем запустить мои тесты для (статической) структуры данных (псевдокод):

private static Object resultData = null;

@BeforeClass
// Read/Write my stuff here
resultData = ....

@Test
// Check my requirements
assertTrue(resultData....);

Проблема в том, что я могу изменить ожидаемое поведение внутри методов тестирования, поэтому мои тесты больше не являются автономными.

Как бы вы справились с этим?

Answer 1

Как бы вы справились с этим?

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

В частности, я хотел бы создать такие швы, чтобы

1. Код, который реализует ввод / вывод, слишком прост, чтобы его потерпеть неудачу
2. Весь сложный код не заботится о том, как осуществляется ввод / вывод.

На языке, подобном Java, шов будет интерфейсом. Мой код ввода / вывода будет реализовывать интерфейс, но сам по себе не будет выполняться в тесте.

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

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

Корень композиции для производственного кода, конечно, должен создать экземпляр «реальной» реализации для использования. Но корень композиции для теста может вместо этого выбрать двойной тест, или файловую систему в памяти, или что угодно, чтобы гарантировать, что результаты теста являются детерминированными (и, между прочим, не влияют на время жизни вашего SSD).

Эвристика для того, какой код живет за сценой, приходит к нам из Hoare

Один из способов [разработки дизайна программного обеспечения] состоит в том, чтобы сделать его настолько простым, чтобы, очевидно, не было недостатков

Answer 2

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

Вы об этом думаете: DWPD (Drive Writes Per Day) до 1 для SSD Disk (что сегодня достаточно стандартно) подходит для многих случаев использования.
DWPD измеряет, сколько раз вы могли перезаписывать весь размер диска за день его работы.
Для диска 500 GO значение DWPD до 1 означает, что теоретически вы можете писать 500 GO в день, пока не наступает гарантийный срок на продукт.
И это, как правило, от 5 до 10 лет.
Таким образом, некоторые временные файлы, создаваемые в каждой сборке (100 или более), являются практически ничем иным, как если бы вы выполняли несколько миллионов сборок в день.

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

При этом все же имеет смысл избегать записи файлов в модульных тестах, поскольку тесты должны выполняться быстро.
Вы можете изменить API тестируемого класса, чтобы он также принимал ByteArrayInputStream и ByteArrayOutputStream. Таким образом, чтение и запись будут работать в памяти, а не в файловой системе.