Томаш Лелек , Джон Скит - Software: Ошибки и компромиссы при разработке ПО

тестах не рекомендуется, но вскоре вы увидите, как исправить этот недочет. Наконец, мы
проверяем, что полученное значение равно 6.
Листинг 9.12. Тестирование реактивной обработки: обобщенное решение
// Дано
Flux data = Flux.fromIterable(Arrays.asList(1, 2, 3));

9.3. Тестируемость

305

Thread.sleep(10_000);
// Если
Flux result = sumElementsWithinTimeWindow(data);
// То
assertThat(result.blockFirst()).isEqualTo(6);

К сожалению, в логике есть проблемы. Сначала в ней используется приостановка
потока, которая увеличивает время на выполнение модульного теста. В реальной
системе пришлось бы провести намного более масштабное тестирование и отработать больше сценариев. Это увеличило бы время, необходимое для всех
модульных тестов, до неприемлемого уровня. Во-вторых, применение такого
подхода к тестированию усложняет проверку в более сложных сценариях. Например, как убедиться, что значение после 10 секунд не будет учтено? Нужно
выдать другое значение, подождать некоторое время, а потом проверить результаты. Анализируя этот простой пример, мы видим, что даже при использовании
хорошей библиотеки без тестовой инфраструктуры провести тестирование
крайне сложно, а иногда и вовсе невозможно.
К счастью, библиотека, используемая в этой главе, предоставляет тестовую
библиотеку. Для реактивного тестирования используется библиотека reactortest (http://mng.bz/8lPz). Это позволяет упростить тесты и делает возможным
тестирование более сложных сценариев.
Для тестов мы используем класс TestPublisher, который позволяет предоставить
данные для реактивного потока данных (листинг 9.13). Также с его помощью
можно моделировать задержки без фактического замедления общего времени выполнения запросов. Приостановка для этого не нужна, поэтому тесты
будут завершаться практически мгновенно. TestPublisher передается классу
StepVerifier. Оба класса предоставляются библиотекой реактивного тестирования, которая совместима с реактивной рабочей библиотекой.
Листинг 9.13. Тестирование реактивной обработки с использованием
тестовой библиотеки
final TestPublisher testPublisher = TestPublisher.create();
Flux result = sumElementsWithinTimeWindow(testPublisher.flux());
StepVerifier.create(result)
.then(() -> testPublisher.emit(1, 2, 3))
.thenAwait(Duration.ofSeconds(10))
.then(() -> testPublisher.emit(4))
.expectNext(6)
.verifyComplete();

Класс StepVerifier позволяет сгенерировать значения, выждать заданное время
без блокирования, а затем сгенерировать значения снова. В нашем тестовом

306

Глава 9. Сторонние библиотеки: используемые библиотеки становятся кодом

сценарии снова будут сгенерированы значения 1, 2, 3. После этого имитируется 10-секундная задержка, равная размеру окна. Затем генерируется еще одно
значение. Наконец, мы проверяем, что первое произведенное значение равно 6.
Таким образом, значение, сгенерированное после длины окна, не было включено
в первое окно.
Этот подход позволяет протестировать любой сценарий, который приходится
учитывать. Кроме того, сам факт тестирования задержки не означает, что модульное тестирование будет занимать больше времени. Тесты будут выполняться
быстро, и мы сможем создать много модульных тестов для покрытия логики,
реализованной с использованием реактивной библиотеки.
ПРИМЕЧАНИЕ
Многие библиотеки предоставляют в распоряжение разработчика тестовую библиотеку. Часто ее наличие становится признаком высокого качества и упрощает разработку.

Рассмотрим второй аспект тестируемости для сторонних библиотек — способы
внедрения ложных объектов (fake) или имитаций (mock).

9.3.2. Тестирование с использованием объектов
fake (тестовых двойников) и mock
Другой важный аспект, на котором следует сосредоточиться при принятии
решения об использовании сторонней библиотеки, — возможность внедрения
объектов, предоставленных пользователем, для целей тестирования. Таким
объектом может быть имитация mock, с помощью которой можно смоделировать и проверить конкретное поведение, или объект fake (тестовый двойник),
позволяющий предоставить данные или контекст тестируемому коду. Часто
библиотеки скрывают слишком много внутренних подробностей от источника
вызова, защищаясь от потенциальных злоупотреблений со стороны пользователей. Однако это может затруднить тестирование библиотеки.
Если вам доступна кодовая база библиотеки, найдите в ней точку создания
нового экземпляра. Невозможность внедрения альтернативной реализации
для целей тестирования указывает на будущие проблемы с тестированием. --">