Мы продолжаем рассказывать о вариантах оптимизации тестирования, которые можно применить как внутри тестов, так и, условно, снаружи, т. е. в обертках и прочих внешних инструментах.
В прошлой части уже описали некоторые «внешние» инструменты (ссылка). Сегодня поговорим о возможностях внутри самих тестов.
Текст подготовлен по материалам выступления приглашенного спикера внутри компании.
Делаем понятные описания к запросам API
Распространенный способ описывать запросы API в тестах — просто прикреплять к сабстепу текстовый файл. С точки зрения погружения в тесты человека со стороны это очень неудобный формат. Возможно, на проектах, где все знают, как быстро запустить тест или воспроизвести запрос, это и работает. Но гораздо чаще человеку со стороны приходится искать аналогичную Postman‑коллекцию, перебивать в свой инструмент параметры запроса и т. п. Это довольно длинный путь, на который уходит много времени.
Гораздо удобнее использовать для описания запросов cURL. Это унифицированный формат, запись в котором легко скопировать в консоль и выполнить. Такой подход упрощает жизнь в том числе и devops‑ам, которые могут смотреть логи тестов.
Чтобы включить эту возможность в своем проекте, рекомендуем посмотреть библиотеку cURL logger. Она маленькая — всего восемь классов. Кажется, перетянуть ее на другой язык — это всего пара дней работы.
Вводим уникальные сообщения об ошибках
Многие автотестеры забывают про читаемые сообщения об ошибках — пишут в лог только не особо репрезентативный локатор и цепочку вызовов до того, пока тест не упал. У самого тестера глаз наметан — он знает, где искать причину. Но у аналитиков или менеджеров проекта от такого описания дергается глаз.
Делайте читаемые сообщения об ошибках. А еще лучше, если они будут уникальными, чтобы в каком‑нибудь Allure не было потом одинаковых сообщений для разных дефектов. Иногда удобно даже скриншот прикреплять, чтобы новеньким было удобнее смотреть, с каким элементом ассоциируется тот или иной класс.
Правильно управляем тестовыми данными
Не стоит забывать, что тестовыми данными нужно управлять. Кто‑то из тестеров может копипастнуть данные или обратиться из разных тестов к одним и тем же сущностям. Такое поведение может вызывать конфликты, флакирование тестов и много других неприятностей.
Чтобы не бороться с этим по факту, лучше разделять тестовые данные по пользователям и в целом сократить переиспользование между разными тестовыми наборами. Для автоматической генерации данных можно использовать библиотеки типа Faker (https://github.com/fzaninotto/Faker). Это опенсорсная библиотека на PHP, которая умеет генерировать данные (вплоть до создания красивых XML‑документов) или анонимизировать данные, взятые с прода.
Ну и старайтесь не забывать про очистку данных. Если тест падает, нужно прогнать пост‑фикстуру. Это может быть нетривиальная задача — смотря какой тест. Если, допустим, первый API запрос на создание заметки в рамках теста был выполнен, а потом тест упал, необходимо вычистить только эту заметку. Это не всегда так просто. Иногда нужно писать специальную «очищалку» — брать лог с запросами cURL, анализировать его и удалять созданные или измененные артефакты.
Можно использовать другой подход — пресеты. Это в большей степени уже про тестовый стенд, нежели про фреймворк. В рамках этого подхода тестировщик поднимает пресет стенд, заводит в нем все данные, необходимые для тестов, и создает бекап всего этого в хранилище S3. Для тестирования потом каждый раз разворачиваем стенд из эталона — т. е. уже не управляем данными, а работаем с DevOps‑практиками.
Подход также спорный. Как правило, его можно применять либо для монолита, у которого нет кучи базы данных, либо для отдельно взятого сервиса с одной базой. Кроме того, если в S3 кто‑то залезет, вы можете все потерять — это неудобно.
Рекомендую в целом периодически анализировать, сколько по времени выполняются те или иные шаги. Если у вас есть какой‑нибудь продукт JetBrains (желательно версии Ultimate), он подскажет, где есть проблемы с производительностью. Но если его нет, можно ту же информацию получить из отчета Allure.
P. S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на нашу страницу в VK или на Telegram‑канал, чтобы узнавать обо всех публикациях и других новостях компании Maxilect.