Автотестирование больших веб-проектов: для чего и как мы пишем автотесты

Код должен всегда работать корректно. Это главное правило разработчика. Когда работаешь в большой команде, где каждый делает свою часть общего проекта, важно обеспечить согласованность действий. Для этого мы и пишем автотесты. Цель автотестирования: обеспечить качество продукта, а также убедится в том, что твой код не поломают. В этой статье Front-end разработчик Виталий рассказывает об автотестировании на одном из его проектов.

Виталий, Front-end разработчик 

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

Для того, чтобы говорить об автотестировании более предметно, я расскажу об одном из наших веб-проектов, где мы пишем такие тесты. Сначала поговорим о самом автотестировании на проекте, с легальных причин дальше будем называть его проект A, а затем объясню, как автотесты внедрить в continuous integration (CI).

Как реализовано автотестирование на проекте 

Автотестирование у нас реализовано с помощью такого фреймворка, как Behat. Эта библиотека заточена специально под Behaviour driving development, или BDD. Суть “идеологии” BDD в том, что сценарии, описанные человечески понятным языком, не обязательно на английском - называется он Gherkin - переводятся в тесты, с которыми справляется уже фреймворк, в данном случае Behat. Цель синтаксиса языка Gherkin в том, чтобы дать возможность не техническим специалистам описать требования к работе продукта. 

На каждый отдельный тест кейс пишется свой сценарий за принципом “given-when-and-then” (что имеем-если-и-тогда). Это делается для того, чтобы потом мы могли перечитать эти тесты и лучше понять, как работает система. Мы можем дать клиенту, заказчику или его менеджеру, этот так называемый план “given-when-and-then”, чтобы он описал свое видение задачи. Допустим мы делаем авторизацию на сайте и будем писать автотест на валидацию формы. Сценарий для автотестирования будет такой:

Feature: Sign up (Название: авторизация)
Scenario: Check validation (Сценарий: проверка валидации)
Given I am on the sign up page (Что имеем: я нахожусь на странице регистрации)
When I fill in the "E-mail" field (Когда я заполняю поле "E-mail")
And I do not fill in the "Password" field (И не заполняю поле “Пароль”)
Then I see an indicator of validation error (Я вижу индикатор ошибки валидации)

По сути с помощью тестирования мы имитируем взаимодействие пользователя с будущим веб-продуктом и локализируем ошибки, если такие есть. Фреймворк Behat обрабатывает то, что написано на человечески понятном языке. Он читает текст и ищет совпадения в определенных файлах по ключевым словам. Находит тест кейс, и прогоняет код через автотестирование. Программист, в свою очередь, использует этот фреймворк, чтобы под кейс, написанный на человеческом языке, написать программный код, который будет выполнять эти тесты.

Как интегрировать автотестирование в Continuous Integration

Что представляют собой continuous integration tools и для чего они нужны? Существует много инструментов непрерывной интеграции. Непосредственно на  проекте A мы используем Circleci. В нашем случае, мы используем эту программу, чтобы следить за исходным кодом. Все изменения мы заливаем на git-репозиторий. Когда в проекте появляются изменения, программа автоматически билдит их и прогоняет через тесты. В случае обнаружения ошибки, она оповещает нас об этом. В первую очередь программка предупреждает разработчика, который последним вносил изменения в код. На почту ему прилетает оповещение о том, где произошла ошибка, что стало ее причиной, и он быстро ее исправляет. На продакшн сервер такие изменения не попадут. Если автотестирование прошло успешно, она отправляет изменения на продакшн. 

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