Боль при параллелизации тестов

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

Сейчас писать автоматические тесты умеет практически каждый. Роль автоматизации растет, все больше проектов начинают применять автоматизацию тестирования в том или ином виде. Большинство людей думает, что делать автоматизацию - это просто. Смотрим пару роликов в Youtube, берем связку Selenium + TestNG и все - мы автоматизаторы, которые будут делать успешную автоматизацию. В такие моменты у людей, познавших дзен, находится только один аргумент:

Чего не учитывают многие, стартуя автоматизацию у себя на проекте?

Почему эти вопросы нужно задавать себе? Потому что архитектура и проекта, и самих тестов будет зависеть от этих факторов. Особенно если перед вами стал вопрос параллелизации тестов.

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

Вот к каким выводам я пришел впоследствии.

Если пишем автотесты для REST API, то никаких зависимостей между тестами быть не должно! Эти тесты сами по себе достаточно быстрые и нужда в их параллелизации возникает редко, но даже если уж так все у вас долго и хочется из 5-10 минут выжать 1 минуту, то проблем быть не должно, так как CRUD операции параллелятся на раз-два. Единственное, где вы можете напороться на проблемы, - это уникальность данных.

Если пишем автотесты на UI, то здесь может возникнуть масса сложностей. Обычно основным источником являются тесты, тестовые данные, браузеры и их драйверы.

Если пишем автотесты на UI, то здесь может возникнуть масса сложностей. Обычно основным источником являются тесты, тестовые данные, браузеры и их драйверы.

Да, благо что есть Selenium Grid, но и при работе с ним возникает куча проблем. К примеру, отвалившаяся или зависшая нода. Да, все эти проблемы решаемы, но я бы начал решать проблемы еще на этапе самой задумки.

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

Первое: следует подумать, а нужно ли нам так много UI тестов? Может быть, мы будем проверять только функциональность нашего UI, а не всякие рюшечки, для которых Selenium не придумывался? Лучше иметь 100, но стабильных тестов, чем 1000 постоянно требующих внимания нестабильных.

Второе: нужно сначала попытаться оптимизировать тесты на уровне кода. Пример из моего проекта: у нас было 500 UI тестов (да, можно сказать,что до хрена, но там была риск менеджмент система с кучей формочек и попапов) и общее время прогона тестов на тот момент составляло 16 часов!!. Я понимал, что у нас не все ОК, и начал искать узкие места в коде. Поубирав все Thread.sleep и переписав пару методов на вызов JS функций, я сократил время в два раза и у нас появилась возможность прогонять их за 8 часов. Таким образом мне удалось ускорить тесты и сохранить их стабильность и работоспособность.

Самая большая боль параллельных UI тестов - их высокая нестабильность. И перед тем, как сказать "да, мы готовы к нестабильным тестам", подумайте: а оно вам нужно? Лично я отдаю предпочтение стабильным и надежным автотестам, что подтверждается графиком из Jenkins:

image::/images/jenkins_trend.jpg

На этой мажорной ноте желаю вам думать о параллелизации еще на самом старте проекта и отдавать предпочтение автоматизации, которая делает свою работу и приносит пользу проекту в целом. Спасибо, что вы с нами…​