О проекте

Проект retailCRM стартовал в 2013 году. Тогда это был внутренний стартап с ограниченным функционалом, не требующим проведения тестов.

Спустя год размер проекта стал внушительнее, и уже начали задумываться о тестировании в проекте. Параллельно требовалось обновление версии фреймворка Symfony, на котором разработан продукт. На тот момент система работала на Symfony 2.1, хотя уже тогда вышел Symfony 2.5.

Чтобы идти в ногу со временем и не дать коду проекта устареть, требовалось обновить Symfony. Обновление сопровождалось значительными рисками, т.к. версии достаточно сильно отличались и можно было получить многочисленные ошибки. Всё это послужило поводом для написания первого набора тестов.

Сначала были написаны базовые тесты, которые просто обходили все странички системы, отправляли формы, фильтры, включали сортировки и проверяли отсутствие 500-х ошибок, что позволяло выявить самые очевидные поломки после обновления.

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

Также были добавлены тесты на бизнес-логику, по переходам статусов, проверке прав для доступов в разделы. Весь этот функционал был написан за месяц. В июле 2015 года было принято решение, что написанных тестов (на тот момент их было около 300) достаточно для того, чтобы обновить систему.

После обновления Symfony мы стали писать тесты в обязательном порядке для всех новых задач, по ходу дела покрывая тестами и старые задачи.

Чем больше становилось тестов, тем дольше они прогонялись. Когда была только первая партия тестов, они прогонялись, буквально, в течение нескольких минут. Их запускали локально, на своих машинах.

Когда прохождение тестов стало занимать десятки минут, для разработчика ожидание прохождения было крайне неудобным. Было принято решение использовать в работе PHPCI — это система, которая позволяет автоматически прогонять тесты. Была произведена интеграция PHPCI с git и Redmine, позволяющая работать автономно.

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

Суть трехсторонней интеграции PHPCI, git и Redmine

1. Есть задача, которую разработчик выполняет в новой ветке в git.
2. Данной ветке присваивается такой же номер, как и у задачи.
3. Разработчик реализует задачу, добавляет на неё тесты, далее выполняет commit и push в центральный репозиторий на сервер.
4. PHPCI автоматически мониторит, какие новые ветки появились, и отслеживает появление нового кода на сервере.
5. PHPCI подхватывает новую ветку и берет из данной ветки проект, разворачивает его и начинает прогонять тесты.
6. Если тесты проходят, то PHPCI уведомляет, что тесты прошли успешно: он автоматически проставляет в задаче статус «Обратная связь» и готовность 80%.
7. Если результат отрицательный (не прошел хотя бы один тест), автоматически проставляется статус, что тесты не прошли. В сообщении, которое выдает PHPCI, есть ссылка. Разработчик может посмотреть, какие тесты не прошли, и проанализировать каждый упавший тест, либо актуализировать тест, если логика верная.
8. PHPCI прогоняет тесты на всех версиях PHP, на которых должен работать проект, и по каждому прогону отмечает результат в задаче.

Цикл реализации задачи от постановки до момента попадания задачи на боевую CRM-систему с использованием автотестов

Применение автотестов в других системах

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

• Billing;
• Deployer;
• Geohelper;
• Daemon Collector и др.

Для каждого из этих проектов разработаны свои тесты. Тесты прогоняются на всех мажорных версиях языка, которые поддерживаются проектом. На данный момент минимальные требования у retailCRM ≥ PHP5.6, и каждая задача прогоняется на PHP5.6 и PHP7.

Данные, проверяемые при автотестировании

1. Данные, проверяемые при автотестировании
2. Выкладка про unit-тесты для API

Функциональные тесты для бизнес-логики Функциональные тесты на порядок тяжелее unit-тестов. Они требуют перезаливки тестовых фикстур в БД и эмулируют полноценную request/response-логику. Например, CI начинался на средней виртуалке на 4х ядрах и прогон тестов занимал 10-20 минут, а за два года на этой виртуалке время прогона выросло до 3-5 часов. После ряда оптимизаций и переезда на выделенный сервер удалось уменьшить время до 45 минут.

Достигнутые результаты

1. Решение проблемы локализации ошибок при обновлении фреймворков и библиотек, используемых в проекте. Обновление версии Symfony происходит в штатном режиме с доработкой кода в местах упавших тестов.
2. Сокращение времени техлида на проверку кода.
3. Быстрое и стабильное внедрение новых фич.

Салихов Ильяс, СТО RetailCRM:

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

По данным на август 2016 г разработано уже более 2000 тестов. В этих тестах выполняется почти 40 тысяч различных проверок той или иной логики работы сервиса retailCRM. Без внедрения автотестов это было бы практически невозможно."

Перейти на сайт