День 1487. #Testing
Ода Юнит-Тестам: в Защиту Пирамиды Тестирования. Окончание
Начало

Моки: всё или ничего
При подходе к тестированию методом белого ящика часто используются моки. Но когда вы злоупотребляете ими, поддерживать тесты становится сложнее. Возможно, это то, что имеет в виду Марк Симанн, когда говорит, что заглушки и моки нарушают инкапсуляцию. Как только вы начинаете сталкиваться с такой проблемой из-за тяжёлых моков, нормально начать их ненавидеть и пытаться избежать любой ценой. Подход, основанный только на тестировании API, обычно приводит к необходимости интенсивного использования моков. Так это проблема моков или неправильного их использования?

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

Уменьшите публичность вашего кода
Ещё один побочный эффект тестирования методом белого ящика в том, что оно приводит к раскрытию большего количества кода, чем необходимо. Валидаторы, мапперв и другие фрагменты кода, которые могут быть деталями внутренней реализации, теперь являются частью публичного контракта только потому, что мы предоставили их для тестирования. Кроме того, любой, кто работает в мире Java и C#, знает, насколько распространены интерфейсы в их кодовых базах. Опять же, ради тестов. Разработчик может ввести интерфейс, только чтобы имитировать зависимость в тестах.

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

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

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

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

Адаптеры для интеграционного тестирования лишь вносят слабое место в нашу стратегию тестирования. Когда вы проводите интеграционное тестирование со всеми подключёнными компонентами, вы получаете преимущество тестирования таких вещей, как конфигурация и композиция. Очевидно, мы хотим это проверить. Мы по-прежнему можем запускать тесты со всеми подключёнными компонентами. Разница в том, что они должны быть «дымовыми тестами», а не запускаться для тестирования каждого отдельного случая. Это приводит к более стабильным и надёжным тестам.

Источник: https://www.infoq.com/articles/unit-tests-testing-pyramid/