Прежде чем приступить к автоматизации тестирования, желательно проанализировать приложение. Чем больше приложение готово к автоматизации, тем меньше проблем будет в дальнейшем при разработке автотестов и анализе результатов.

Одним из ключевых факторов успеха автоматизации является тестируемость приложения. Благодаря тестируемости автотесты пишутся проще и быстрее. Например, для API это публичные методы, а для UI это HTML страница.

0. Готовность приложения

Бывает так, что автоматизируют слишком рано, и в итоге потом занимаются переписыванием. Как можно раньше задайтесь вопросами, а готовы ли основные страницы для автоматизации, целесообразно ли брать в работу, не поменяется ли логика или вёрстка на следующий день и т.д.

1. Доступность документации

Документация помогает быстрее найти нужную информацию, например, для создания тестовых данных через API. Swagger и Storybook позволяют легко документировать API и UI компоненты соответственно.

На основе спецификаций можно генерировать тесты. С использованием Storybook можно узнать нужное состояние компонента и его назначение. 

Также, на основе документации можно построить покрытие автотестами, как это рассказано на примере инструмента swagger-coverage.

2. Расставляем data-* атрибуты

Для уменьшения количества падающих тестов, если фронтенд будет меняться, и для удобного нахождения элементов в DOM, необходимы надёжные локаторы. 

Менее подвержены изменениям data-* атрибуты, например, data-test="element".

Не так давно на конференции Heisenbug в докладе «Как Testid-strategy победила PageObject и BDD/Cucumber монстров» было рассказано о преимуществе подобного подхода в связке с Allure Report.

Можно использовать и другие локаторы, если такие существуют. Приоритетность можно посмотреть в Testing Library. В первую очередь рассматриваем приближённые к пользователю локаторы. Сразу бонус тем, кто следит за accessibility продукта. 

3. По возможности отключаем анимации на время прогона

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

Хорошей практикой является полное отключение подобных анимаций, если это возможно. 

4. Параллельный запуск

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

5. Third-party зависимости

На архитектурных схемах или другой документации можно найти различные third-party зависимости. Контролировать их сложно, поэтому подстроить под тесты проблематично. 

Например, для стороннего API в качестве мок-сервера можно использовать Wiremock или MockWebServer. Таким образом автотесты будут стабильнее.

6. Логи

Логи — наши помощники при анализе и разборе результатов автотестов после прогона. Разбираться с причинами падений становится проще.

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

Некоторые фреймворки позволяют прикреплять логи из разных источников к автотесту. Такими источниками может служить информация из консоли браузера или информация от сервера. 

7. Время ответа приложения

На глобальном уровне обычно выставляется таймаут для всех ожиданий в тестах. Вычислить его можно опытным путём. 

Время ответа не должно превышать заданный таймаут, иначе тесты будут постоянно падать и надо постоянно с ними разбираться. 

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

Заключение

Опираясь на вышеперечисленные советы можно облегчить автоматизацию тестирования приложения.