Разработка автотестов 
для CRM-системы

1. Вводная задача от заказчика, проблематика, цели

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

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

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

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

Наши задачи:

• сохранение стабильной работы проекта retailCRM при интенсивном развитии;
• автоматическая проверка новых фич retailCRM в момент их разработки и внедрения в боевую версию системы.

2. Описание реализации кейса и творческого пути по поиску оптимального решения

О проекте

Сначала были написаны базовые тесты, которые просто обходили все странички системы, отправляли формы, фильтры, включали сортировки и проверяли отсутствие 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, на которых должен работать проект, и по каждому прогону отмечает результат в задаче.

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

• выкладка про unit-тесты для API;
• функциональные тесты для бизнес-логики.

3. Результаты сотрудничества

• решение проблемы локализации ошибок при обновлении фреймворков и библиотек, используемых в проекте. Обновление версии Symfony происходит в штатном режиме с доработкой кода в местах упавших тестов;
• сокращение времени техлида на проверку кода;
• быстрое и стабильное внедрение новых фич.

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

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

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

Для каждого из этих проектов разработаны свои тесты.

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

Салихов Ильяс

СТО, Intaro

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