Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Прежде чем приступить к автоматизации тестирования, желательно проанализировать приложение. Чем больше приложение готово к автоматизации, тем меньше проблем будет в дальнейшем при разработке автотестов и анализе результатов.
Одним из ключевых факторов успеха автоматизации является тестируемость приложения. Благодаря тестируемости автотесты пишутся проще и быстрее. Например, для 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. Время ответа приложения
На глобальном уровне обычно выставляется таймаут для всех ожиданий в тестах. Вычислить его можно опытным путём.
Время ответа не должно превышать заданный таймаут, иначе тесты будут постоянно падать и надо постоянно с ними разбираться.
Оптимальным решением здесь будет обсуждение по поводу улучшения перформанса, возможно есть какие-то проблемы и нужно их решить.
Заключение
Опираясь на вышеперечисленные советы можно облегчить автоматизацию тестирования приложения.
