Алгоритм написания автотестов: GUI

1. Описать сценарии автотестов.

Так же, как и в API, — это основа основ. Важно понимать, что именно и зачем мы хотим автоматизировать.

2. Перечислить страницы, которые будут задействованы в тестах. На каждой выделить элементы, которые будут участвовать в действиях/проверках. Подумать, что будем делать с этими элементами: кликать? Ховерить? Выделять текст? 

3. Проверить, не описаны ли уже эти страницы внутри репозитория с тестами. Если описаны — просто добавляем нужные методы/элементы.

4. Если страницы не описаны, описать их классы по структуре:

В виде кода это будет выглядеть примерно так:

5. Проверить, что Page object не содержит assert’ов.

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

6. Из получившихся методов собрать тесты.

Так как UI-тесты более медленные, нестабильные и затратные по времени, здесь правило «один тест = одна проверка» уже не работает. Это не значит, что стоит пихать в один тест макисмум проверок – но значит, что можно некоторые близкие кейсы «слить» в один.

Дальше многое почти идентично алгоритму по API.

7. Убедиться, что тесты запускаются и работают.

Начать можно с того, чтобы проверить, соберется ли билд. В идеале пошагово пройти их в debugger’е — просто построчно проверять, что у нас результат на каждом шаге совпадает с ожидаемым.

8. Посмотреть на код тестов и найти повторяющиеся куски.

Вынести их в отдельные вспомогательные методы — можно внутри класса тестов, можно внутри класса страниц. Если же метод затрагивает несколько страниц и повторяется в ряде тестовых классов, можно вынести его в отдельный класс-помощник.

9. Посмотреть на код тестов и проверить, нет ли:

• локаторов прямо в коде теста — надо уносить их в классы Page Object;
• JS-скриптов в коде теста — их место тоже в классах Page Object;
• захардкоженных тестовых данных — их лучше выносить или в отдельный класс, или передавать с помощью в DataProvider;
• wait(timeout) или thread.sleep() — ожиданий, которые не завязаны на появление элемента, а выжидают строгий таймаут.

10. Посмотреть на код тестов и убедиться, что:

• все страницы, которые могут открываться по прямой ссылке, открываются по прямой ссылке, а не через боковое меню/UI-навигацию/как-то ещё, как это бы делал пользователь. Исключение — если это тест на навигацию;
• ожидания стоят только на те элементы, на которые завязана логика тестов. UI-тесты относительно медленные и громоздкие — так что было бы грустно замедлять их ещё больше;
• один тест покрывает один пользовательский сценарий. Ассертов может быть несколько, главное, чтобы глобальная идея теста была одна;
• тестовые пользователи не задевают друг друга и не влияют на действия друг друга.

11. Оценить время прогона тестов.

Помним, что UI-тесты медленнее прочих. Если тест занимает слишком много времени относительно прочих, можно подумать над разбиением его на более мелкие проверки.

12. Проверить, не зависимы ли тесты друг от друга. Можно ли их запускать по отдельности? А параллельно?

12. Проверить, не задевают ли тесты логики других тестов в репозитории.

Актуально для случаев, когда мы меняем существующие классы.

13. Отформатировать код по codestyle, проверить отсутствие ворнингов, неиспользованных методов и переменных, ToDo-шек.

14. Отдать тесты на ревью.

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

В общем, я глубоко убеждена, что код-ревью – для всех, в том числе джуниоров и тех, кто не пишет автотесты.

Призываю к обсуждению: что бы вы добавили, что убрали? Какими лучшими практиками вы пользуетесь, когда пишете автотесты?