# E2E тесты на этапе разработки

> Код тестов полезен настолько, насколько он ускоряет процесс разработки.
> Чтобы этого достичь, его нужно встраивать в процесс разработки основного продукта так, чтобы он стал его естественной частью, а не побочной деятельностью(с) *How Google Tests Software*
>>
---

## Вводная часть.

Покрытие фичей E2E-тестами увеличилось за последние 2 года за счёт подключения к автоматизации тестирования Manual-QA, которые прошли внутренний Automation Course.
Подробно о задачах QA по автоматизации написано в статье [E2E Tests development process for manual QA](https://wiki.appulate.dev/display/Appulate/E2E+Tests+development+process+for+manual+QA?focusedCommentId=150376332#comment-150376332)

### E2E-тесты пишутся*:
1) До передачи задачи на ручное тестирование;
2) После передачи задачи на ручное на тестирования, но до мержа задачи в общую ветку;
3) После мержа протестированной задачи в общую ветку. Грубо говоря - тесты идут вдогонку;
4) После релиза задачи. Это самый плохой вариант, т.к. задачу по написанию тестов можно отложить на неопределённый срок.

**Note:** Речь идёт про написание *новых* тестов по релизной функциональности.
Мы сознательно опустим Unit, Интеграционные и API тесты, будем говорить только о E2E-Ui-тестах.

**Идеальным вариант - первый:** готовность E2E-тестов должна быть не позднее передачи задачи на ручное тестирование.

Сейчас разберём его и обсудим:
- Плюсы и минусы такого подхода.
- Когда начинать писать код тестов?
- Какие могут быть трудности с реализацией?

### ➕Плюсы:
- **Ускоряет регресс**: позволит запускать E2E-тесты по новой функциональности на тестовом окружении, т.е там, где будут проходить ручные проверки;
- **Экономия времени на ручных проверках**: к передаче функциональности на ручное тестирование успеете провести ни одну итерацию проверок.
Например:
- при написании автотестов проведёте smoke тестирование,
- поработаете и протестируете вёрстку,
- посмотрите, как отрабатывает бэкенд,
- проведёте исследовательское тестирование и оформите дефекты в задачи(саб-таски);
- **Стабильные тесты**: на раннем этапе разработки фронтендер добавит *data-qa* атрибуты на ваши локаторы и тесты будут стабильнее.
- **Расширение проверок или рефакторинг**: за время, пока идёт ручное тестирование успеете автоматизировать большее кол-во сценариев/покрыть найденные баги тестами;

### ➖Минусы:
- **Частично работающий функционал**: чем раньше подключитесть, тем может быть сложнее: часть функционала отсутствует, баги, соответственно не всё возможно автоматизировать;
- **Усложняется работа с Git**:
- более частые обновления ветки через ребейзы или создание новой ветки и cherry-pick коммитов в неё,
- разрешение конфликтов при обновлении ветки. Чем дольше функциональность будет в разработке, тем больше будет вынужденных обновлений ветки и вероятность конфликтов сильно возрастает.

Замечу, что **главный минус** - это менее комфортная работа с веткой, но при должной практике с Git вы его не будете замечать. А частично работающий функционал при написании E2E вам даст время на проведение иследовательского тестирование, что пойдёт вам в плюс.

## Когда начинать писать код E2E

Нет правила, когда именно QA должен приступить к написанию кода тестов. Всегда нужно действовать по ситуации. Обычно тригером для старта служит готовность фронтенда, т.е. мы пишем Ui тесты и без готового GUI, хотя бы частично, будет сложно писать код самих тестов и мапить элементы.

Поэтому:

- **Следите за разработкой**: постоянно коммуницируйте с разработчиками и задавайтесь вопросами:
- На каком этапе разработка функциональности?
- Можно ли задеплоить код на тестовое окружение, чтобы частично проверить работоспособность фичи?
- Будут ли изменения в вёрстке? Это может сыграть ключевую роль в разработке моделей, например для тестирования грида.
- Добавлены ли *data-qa* атрибуты и на какие элементы?

- **Подготовьте тест-кейсы**: проработайте тестовые сценарии и пройдите их ревью, чтобы как-минимум базовые кейсы были готовы для сквозного тестирования.
- **Перейдите к проектированию тестов и PageObject моделей**: проанализируйте, что вам понадобиться замапить на основе макетов (или готовой вёрстки).
Полезная информация собрана в статье [Рекомендации по разработке PageObject моделей и E2E-тестов на их основе](https://hackmd.io/@newbloodqaa/rJeTpAn38).

## Пишем код тестов, опережаем трудности

Типичный сценарий работы с кодом такой:

1) **Ветвимся от ветки разработки** - как только сайт можно задеплоить и новый функционал на фронте рендерится. Статус задачи *Development in progress*/*Review*.
На этом этапе нужно убедиться, что для всех элементов к которым вы будете привязываться - добавлены **data-qa** атрибуты. Это ускорит мапинг элементов.
Если аттрибутов нет - всегда простите разработчика добавить их. Сами же временно используйте в локаторах *XPath* или *CSS*

2) **Делаем изменения и осознанно коммитим в удалённую ветку**. Осознанные коммиты - помогут нам не запутаться при [ребейзе](https://hackmd.io/yQWowLhDT2K3ZWE2BO--jA), объединить или изменить порядок коммитов, например если будут коммиты с фиксами или часть изменений добавлена как draft или заккоменчена.
Рекомендации по коммитам в статье [Git: Как правильно писать commit-messages](https://hackmd.io/@newbloodqaa/ByYBdHTcL)

3) **Открываем draft-review в GitHub** сразу после первого пуша. Это нужно для того чтобы:
- Делать ревью собственного кода в GitHub.Как [Проверить код тестов перед передачей на ревью](https://hackmd.io/@newbloodqaa/HkojryhoL).
- Поэтапно добавлять описание к ревью и скриншоты, чтобы не делать это в последний момент. С таким подходом ваши PoolRequiest-ы будут понятными для ревьюверов и для истории.

4) **Своевременно обновляем ветку** и резолвим конфликты при их появлении. Тут всё будет зависеть от ситуации и вашего скила. Помогут с обновлением веток заметки:
- [Git: Как сделать rebase на staging (вместо подмерживания staging)](https://hackmd.io/@newbloodqaa/S1k3qZ6Zt)
- [Git: Интерактивный ребейз и как удалить коммиты разработчика из своей ветки](https://hackmd.io/@newbloodqaa/HJnuto_4Y)

Если с обновлением ветки у вас ступор - соберите новую ветку:
- Ветвитесь заново от ветки разработки
- Черипикайте коммиты из старой ветки в новую. Порой так бывает даже легче обновиться.

5) **Запускаем стабилизационные прогоны тестов** или full-прогон в Team City. Не забывайте про те категории тестов, которые по умолчанию не запускаются (добавить ссылку на гайд)

6) **Открываем и проходим ревью в GitHub**

7) **Мержим реквест с тестами в ветку разработки** и запускаем full-прогон тестов в Team City

## Что получаем в итоге
➕Работающий код тестов по новому функционалу до перехода задачи на ручное тестирование -это увеличтит ваш перфоманс и ускорит ручное тестирование.
➕Время на расширение покрытия по функционалу. Например, успеете покрыть функциональность негативными сценариями, или найденные баги, если будет необходимость.
➖Неудобства с обновлением ветки. Если задача будет ещё разрабатываться продолжительное время - возможно будут появлятся конфликты с базовой веткой (это часто зависит от функциональности).

###### tags: `Principles of work` `E2E` `draft`