Лайфхаки по быстрому написанию автотестов или пишем автотесты без боли

Привет, Хабр. Меня зовут Виталий Стародубцев. Я ведущий QA-инженер в СберЗдоровье — MedTech-компании №1 в России.

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

Я с этим нередко сталкивался при анализе сторонних проектов и понял, что подобные ситуации довольно распространены. Поэтому в статье решил собрать несколько простых лайфхаков и практических советов, которые помогают быстрее писать, запускать и отлаживать автотесты: часть из них касается общей работы с кодом и IDE, а часть — специфики автоматизации.

Начнем с азов: общие рекомендации

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

Горячие клавиши

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

• command + C и command + V — стандартные копировать/вставить (куда же без них);

• command + Shift + V — вставляет текст без форматирования;

• command + X — вырезает выделенный текст/строку;

• command + D — копирует и сразу вставляет строку/выделенный текст;

• command + O — выполняет поиск классов/методов;

• option + ЛКМ — выполняет метод/получение данных из переменной (тоже самое, что выполнить через Evaluate Expression);

• command + N — генерирует основные методы, конструкторы;

• command + ? — комментирует/раскомментирует «//» выделенные строки;

• command + shift + N — создает временные файлы. Полезно, когда нужно проверить код, потому что файл не затрагивает проект; 

• command + option + L — команда для выравнивания текста, удаления; импортов и просто чистки. Полезно выполнять после того, как все в классе написано;

• command + shift + U — приводит выделенный текст к верхнему/нижнему регистру;

• fn + shift + F6 — команда для редактирования имени переменной/метода/класса (меняет сразу во всех местах, где используется).

Брейкпоинты

Перезапуск тестов занимает время, поэтому можно поставить код на брейкпоинт и описывать локаторы, методы и классы прямо во время выполнения теста.

На следующем запуске останется только проверить:

• корректность локаторов;

• работу методов;

• корректность логики теста.

Это значительно ускоряет разработку и помогает с дебагом.

Если хочешь узнать о том, какие задачи мы решаем — заходи в ТГ-канал SberHealth IT 🙂

Умные брейкпоинты (Condition Breakpoints)

Помимо простых, есть еще и умные брейкпоинты: когда ставите брейкпоинт и нажимаете на него, появляется окно, где можно указать условие, при котором выполнение кода остановится.

Как это можно использовать?

Например, тест падает на строке не всегда, а только при определенных обстоятельствах. Чтобы не перезапускать тест много раз, можно указать условие, по типу:
patient == null

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

Evaluate Expression (option + fn + F8)

Мощный инструмент. Он позволяет писать и выполнять код прямо во время выполнения теста, пока оно остановлено на брейкпоинте.

Так, без изменения кода проекта можно:

• вызвать методы;

• проверить значения переменных;

• выполнить кусок логики;

• протестировать локатор.

Работа со Stack Trace

Stack Trace — очень полезная штука. Неважно, где он получен — в CI, логах или в консоли. Его можно просто вставить в проект.

IDE автоматически:

• распознает классы;

• подсветит строки;

• позволит перейти в место падения.

Синим цветом выделены классы и строки, которые есть в проекте — на них можно воздействовать.

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

Плагины

Плагины могут очень сильно ускорить разработку.

Например, может быть полезен @mega_generator_plugin — плагин, позволяющий быстро создавать DTO и DAO (спасибо Нечаеву Антону).

Также стоит посмотреть плагины для:

• генерации тестовых данных;

• форматирования кода;

• работы с JSON;

• генерации Page Object.

Мобильные автотесты

Автоматизация тестирования мобильных приложений имеет ряд особенностей по сравнению с веб.

Это обусловлено тем, что в мобильных тестах добавляются дополнительные факторы нестабильности:

• разные версии ОС;

• разные размеры экранов;

• особенности эмуляторов и симуляторов;

• нестабильность драйверов;

• долгий запуск приложений;

• проблемы с кешем устройства.

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

Далее несколько практических советов, которые реально экономят время.

Использование устройства как в CI

Могут возникать ситуации, когда тесты проходят локально, но падают в CI.
Это может быть обусловлено тем, что отличаются:

• версия ОС;

• модель устройства;

• разрешение экрана;

• версия симулятора/эмулятора.

Поэтому желательно использовать такую же конфигурацию устройства, как в CI.

Это позволит:

• избежать различий в верстке;

• уменьшить количество проблем с локаторами;

• снизить количество нестабильных тестов.

Использование более свежих версий APK / IPA

Желательно использовать последнюю сборку приложения. Это позволит быстрее заметить изменения и обновить тесты, даже если разработчики изменили локатор, поменяли структуру экрана или добавили новый элемент.

Чистка кэша эмулятора / симулятора

Эмуляторы и симуляторы сохраняют данные приложения между запусками. Это может приводить к разным проблемам. Например:

• приложение не запускается;

• приложение падает;

• тесты ведут себя нестабильно;

• ломается авторизация.

Но иногда решить проблему можно довольно быстро. Достаточно:

• очистить данные приложения;

• сбросить симулятор;

• перезапустить эмулятор.

Актуализация версий Appium, драйверов и XCUITest / UiAutomator

Стабильность автотестов сильно зависит от версий Appium, драйверов и XCUITest / UiAutomator. Причем иногда после обновления Appium драйверы нужно обновлять отдельно.

Полезные команды:

• appium driver list;

• appium driver update.

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

Полезные аргументы Appium

Помочь в работе могут и некоторые аргументы Appium.

• appium:newCommandTimeout: 9000. Если выполнение остановилось на брейкпоинте, драйвер может закрыться из-за таймаута. Этот параметр увеличивает время ожидания команды. Очень удобно во время дебага.

• appium:platformVersion: 18.0. Иногда симулятор iOS может не запускаться из-за конфликта версий. Явное указание версии платформы часто решает проблему.

• appium:simulatorStartupTimeout: 300000. Бывает, что симулятор запускается очень долго. Этот параметр увеличивает время ожидания запуска.

• appium:fullReset: false. Аргумент позволяет не перезапускать эмулятор каждый раз. Это сильно ускоряет запуск тестов.

Использование Page Object

Использование Page Object — базовая практика, но её часто игнорируют. Page Object позволяет:

• вынести локаторы в отдельный класс;

• переиспользовать код;

• уменьшить количество дублирования.

К тому же, при изменении локатора нужно поменять одну строку, а не десятки тестов.

Использование deep link

Если приложение поддерживает deep links, можно значительно ускорить тесты.
Например, вместо того, чтобы открыть приложение, указать логин и перейти на нужный экран, можно сразу открыть экран, используя myapp://profile. 

Это экономит десятки секунд на каждом тесте.

Корректное добавление ожиданий 

Одна из частых причин нестабильности тестов — неправильные ожидания.

Лучше использовать:

• explicit wait;

• ожидание появления элемента;

• ожидание кликабельности.

При этом желательно избегать Thread.sleep(), поскольку это замедляет тесты и делает их нестабильными. 

Заключение

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

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