Рефакторинг как положено. Часть 2 — покрытие тестами

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

Итак, каков желаемый результат рефакторинга? Более качественный код, который работает не хуже, чем раньше. Почему всего лишь “не хуже”? Потому что повышение качества кода попутно решает целый ряд мелких проблем, о которых мы не знали или считали недостаточно важными. А значит, нам, как минимум, следует убедиться, что все работает, как раньше.

Чтобы все это обеспечить нужен QA инженер. Он составит спеки, а потом проверит их вручную. Запомните: только человек может найти все ошибки и недостатки.

Однако это не значит, что нам не нужны автотесты. Они нужны, в первую очередь, программистам. И вот почему:

• Проект становится ближе и понятнее
• Тесты позволяют покрыть самые распространенные ошибки
• На каждую найденную ошибку пишется тест — ошибки не повторяются
• Самое главное — скорость рефакторинга повышается! Украл, выпил, в тюрьму Написал — проверил, написал — проверил и т.д.

Что можно сделать перед написанием тестов?

Многие авторы утверждают — сначала пишем тесты и только потом лезем в код. Сразу заметим: так не получится. В процессе написания тестов и работы с приложением лезть в код все равно приходится. Не все моменты ясны, и чтобы разобраться, приходится заглядывать внутрь. Вам не нужно задумываться, как это переписать. И даже разбираться, как оно работает. Необходимо лишь добиться понимания того, что делает код.

И вот у нас проблема. Программисту тяжело смотреть на плохой код. Он страдает. Беднягу надо спасать. Самый простой выход из этой ситуации — привести стили кода к привычным — вспомнить о лучших практиках. При этом ни в коем случае не переписывать логику.

Итак, лучшие практики. Начнем со строк и символов. Если можно использовать символ — используем символ. Если нет — одинарные кавычки. Если снова нет — двойные. Если вы видите строку, которая передается в незнакомую функцию — пусть остается строкой.

Далее делаем код ровным. Обращаем внимание на отступы и пропуски строк.

Теперь приводим к одному виду порядок определения в классах (по убыванию):

• подключаемые модули (плагины);
• вызов методов класса, включающих новые методы;
• вызов методов класса, которые конфигурируют класс — сначала методы из гемов, потом «rails»;
• метод «initialize» (если он необходим);
• определение методов класса;
• определение методов экземпляра.

Максимум, что можно поменять в коде:  if — на тернарный оператор. И наоборот, но это уже совсем другая история не приветствуется.

Покрываем логику тестами

Подход к написанию тестов перед рефакторингом приложения отличается от подхода к написанию тестов при разработке. В чем дело? Для рефакторинга нам нужны интеграционные тесты. Это те, что имитируют действия пользователя и потом проверяют результат. Такие тесты “кодонезависимы”. Им плевать на качество и устройство кода. Тест просто показывает: работает он или нет.

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

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

Соответственно в тестах для рефакторинга мы проверяем все удачные и неудачные случаи, кроме контента на странице. Кроме того, лезем в базу и проверяем созданы ли нужные записи. Проверяем абсолютно весь функционал, даже самые редкие случаи. Нужно помнить, что мы работаем с незнакомым нам приложением, которое уже работает в продакшене. А значит, здесь невозможно перестараться.

Составляем QA спецификации

Прежде всего, нам нужна общая информация. Что это за проект? Зачем там нужна эта фича? Кому она поможет? Таким образом, разработчики поймут, что от них требуется и сумеют полностью реализовать пожелания заказчика.

Также необходимо помнить, что хорошая спецификация должна уместиться в 20-39 страниц. Иначе информация не уложится в голове, и вас никто не поймет. Правильная спецификация пишется с помощью таких выражений:

• must/must not (обязательная спецификация);
• should/should not (вариативная спецификация);
• may/may not (спецификация не проработана и оставлена на будущее).

Структура документа спецификации должна содержать ссылки и определения. Она включает в себя следующие пункты:

• Введение;
• Назначение (описываются цели спецификации);
• Описание содержимого (scope);
• Описание системы (system overview) — изначальное состояние системы до внедрения фичи.

Сама спецификация состоит из use cases. Они бывают функциональными (определяют, как выглядит интерфейс и взаимодействия интерфейсов с пользователями) и нефункциональными (различные ограничения, например — требования производительности).

Каждый use case оформляется в виде таблицы, включающей в себя:

• summary (краткое описание и версия);
• rationale (необходимость имплементации);
• users (перечень типов/состояний пользователей для взаимодействия);
• preconditions (описание системы до кейса);
• basic course of events (описание системы во время действия кейса);
• alternative paths (альтернативные варианты работы кейса);
• postconditions (состояние системы после работы кейса).

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

Вывод

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

Не переключайтесь! В следующей статье мы, наконец, опишем процесс рефакторинга!