Вероятно, существуют сотни правил, которые можно и нельзя делать для написания хорошего кода. Этот список может отличаться для разных языков или платформ, и некоторые из этих рекомендаций могут противоречить друг другу. Фактически, помимо использования этих рекомендаций, от разработчиков часто ожидается, что они будут также руководствоваться здравым смыслом. Шаблоны проектирования - классический пример этой дилеммы; Если вы начнете использовать их вслепую, не имея должного понимания и точного варианта использования, вы скоро обнаружите, что эти шаблоны дизайна превратятся в анти-шаблоны.
То же самое и с юнит-тестами. В модульном тестировании вы выполняете тестирование «наименьшего» модуля или компонента вашего приложения. Написать примеры модульных тестов непросто, и их поддержка требует дополнительных усилий. Каждый раз, когда вы вносите изменения в свой компонент, высока вероятность, что вам потребуется либо добавить больше вариантов, либо обновить уже написанные кейсы. В этой статье мы расскажем, как лучше писать код с помощью модульного тестирования.
Пример использования
Давайте рассмотрим случай, когда вы заполняете анкету для пользователей. Визуально анкета выглядит так:
Особенности этого компонента:
- Показать запрос / вопрос
- Параметры, из которых пользователь может выбрать один или несколько вариантов
- Вариант «пропустить сейчас», если пользователь не заинтересован в ответе на какой-либо конкретный запрос.
Мы будем называть этот компонент компонентом с множественным выбором. Теперь вы можете решить превратить весь этот компонент в один файл или разбить его на несколько небольших блоков. Вышеупомянутый компонент можно разбить на:
- Раздел вопросов
- Раздел параметров
- Пропустить раздел
Можем ли мы разделить эти единицы на более мелкие (и, что более важно, это вообще необходимо)? Хотя разделы Вопрос и Пропустить кажутся достаточно маленькими, поскольку каждый из них касается одной проблемы, в разделе Параметры все еще есть несколько проблем.
Разбивка раздела опций
Прямо сейчас у этого компонента есть две проблемы:
- Визуализировать список опций
- Управляйте выбором каждого из этих вариантов
Мы можем разбить компонент на более мелкие единицы, выделив или делегируя ответственность независимым компонентам. Таким образом, меньшие единицы, которые можно создать, разорвав раздел параметров, будут следующими:
- Компонент Option
Это касается визуализации фактического компонента и предоставления API, который поддерживает выбор / отмену выбора, а также показывает текущее состояние компонента. - Компонент OptionList
Отображает только список параметров. Вызов компонента Option для каждого параметра, который должен отображаться пользователю и предоставляет соответствующие данные / функции, необходимые для компонента параметра
Вам может быть интересно, почему нам нужно разбить раздел параметров дальше и, возможно, посчитать это ненужным. Один из ответов на этот вопрос - «модульное тестирование».
Если бы вы выполняли модульное тестирование для раздела параметров, вы не смогли бы протестировать определенное поведение, которое будет частным для компонента; например, выбор варианта. Изменение API ваших компонентов для поддержки модульного тестирования является анти-шаблоном и не рекомендуется. Принимая во внимание, что, разбив раздел опций на опции и список опций, у нас есть компонент, который предоставляет API на уровне опций.
Вывод
Написание модульных тестов не всегда возможно, и это не разовая задача. Если вы пишете примеры модульных тестов, вам также необходимо поддерживать их; в зависимости от того, сколько у вас технологической полосы пропускания и каковы ваши приоритеты как команды и организации.
Даже если у вас нет времени на написание тестовых примеров или вы еще не начали их писать, если вы рассмотрите вопрос «а что, если мне придется написать тестовый пример?» при выборе архитектуры вашего приложения / функции (и особенно на этапе реализации) это поможет вам разбить код на более мелкие единицы, которые являются предпосылками для эффективных модульных тестов.
