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

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

Текст подготовлен по материалам выступления приглашенного спикера внутри компании.

Вспоминаем про конфигурируемость оберток

Тестируя системы, мы всегда взаимодействуем с их интерфейсом. Под распространенные технологии, как правило, есть уже готовая библиотека или драйвер. Для UI в таком качестве можно взять довольно популярные Playwright, Selenium, Selenide; для API - OkHttp или REST Assured. Этот список можно продолжить практически для любого интерфейса или протокола.

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

Обертка должна обладать следующими свойствами:

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

• Должна быть независимой.

• Должна быть легко заменяемой. В теории легко заменить должно быть не только модуль, но и библиотеку, поверх которой он существует. Например, мы должны иметь возможность быстро перейти с Playwright на Selenium, глобально не переписывая обертку.

• Должна допускать конфигурацию.

Как правило, на проектах реализуют обертки, соответствующие первым трем пунктам, но забывают про конфигурирование. Покажу на примере, почему так делать не стоит. 

Предположим, мы используем паттерн Page Object. Такую обертку часто включают в качестве примера в различные курсы. В рамках паттерна мы представляем каждую страницу в формате класса, описываем локаторы элементов на этой странице и методы, как с ними можно взаимодействовать. Получаем класс, в котором над стандартными обертками Selenium или Playwright реализованы, допустим, шаги Allure — их можно использовать для разных страниц.

Иногда в код обертки зашивают настройки браузеров (все же работали с Chrome‑option?). И в этой ситуации каждый раз, когда Chrome обновляется так, что меняются настройки, обертку приходится допиливать вручную — через merge request и его апрув. Это слишком много лишних действий.

Гораздо удобнее хранить все настройки где‑то, например в конфиге.

Оптимизируем хранение настроек

Как правило, на проекте есть файл Config. Туда вносятся URL стендов и сервисов, которые с ним связаны, а зачастую и логины‑пароли к ним (это плохая практика, но разговор сейчас не об этом).

Как отмечено в предыдущем пункте, удобно настройки браузеров тоже вынести в конфигурационный файл. Но хранить их по принципу ключ‑значение через знак равно неудобно. Если собрать все браузеры, получается большой нечитаемый Config.

Для хранения подобных настроек есть более удобный формат — HOCON (Human Optimized Config, ссылка). Он имеет достаточно удобный синтаксис, основанный на JSON, но лишен его формальности — обязательных запятых, кавычек и т. п. При этом в файле остаются пары ключ‑значение и структуризация — все гораздо нагляднее.

Читать такие конфиги помогает библиотека TypeSave Config на Java, т. е. использовать HOCON можно на любых JVM‑языках. Кстати, в этой библиотеке предусмотрены методы, которые сразу возвращает Int или List — не нужно возиться с преобразованиями.

Сохраняем логины и пароли

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

Идею можно использовать в любом из мейнстримных языков. Разве что у Playwright, который зачастую используется для тестирования на JS, подобные вещи хорошо реализованы своими средствами.

Оптимизируем фикстуры

Перед запуском теста надо готовить (очищать) окружение. Если мы говорим про UI‑тесты, то одной из самых «дорогих» по ресурсам операций является поднятие браузера. И здесь можно использовать разную стратегию:

• Можно поднимать браузер для каждого теста — в этом случае среда будет чистой.

• Можно переиспользовать поднятый браузер для группы тестов. Но в этом случае есть опасность неочищенного контекста.

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

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

Полезные инструменты

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

Gonkey

https://github.com/lamoda/gonkey 

Это достаточно удобный инструмент для тестирования API. С его помощью можно потыкать Redis и кучу всего.

Тест на этом инструменте пишется в формате YAML‑конфига. В это удобно погрузиться и не нужно трудоемко поддерживать, как с DSL. Инструмент поддерживает:

• различные сценарии валидации ответов

• мокирование внешних HTTP‑сервисов

• поддержка SQL‑фикстур

• интеграция с Go Test

• параллельный запуск тестов

Инструмент со своими минусами. Он существует только на Go и не имеет UI. Также его конфиги могут быть громоздкими.

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

Утилита распространяется по MIT‑лицензии, а развивается силами Lamoda Tech.

Pyresttest

https://github.com/svanoort/pyresttest 

Аналогичная штука есть для Python, только работающая с конфигами. С ее помощью можно:

• просто писать тесты на YAML или JSON;

• гибко работать с тестовыми данными;

• использовать различные варианты валидации ответов;

• включать бенчмаркинг;

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

Правда, по сравнению с Gonkey здесь меньше функций, связанных с SQL-фикстурами, тестированием Redis и т.д.

Из недостатков:

• ограниченная логика тестов;

• нет GUI (только CLI и YAML/JSON);

• риск громоздких конфигов (у Gonkey он также присутствует);

• медленное развитие исключительно силами сообщества;

• плохая документация.

Распространяется по лицензии Apache 2.0. Есть открытый репозиторий на GitHub (ссылка). Можно потыкать и забрать себе.

На этом все. В следующей части продолжим разговор про оптимизации уже внутри тестов.

P. S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на нашу страницу в VK или на Telegram-канал, чтобы узнавать обо всех публикациях и других новостях компании Maxilect.