Comments 5
Спасибо за интересную статью. Расскажите, пожалуйста, следующее:
Во сколько потоков у вас запускаются GUI тесты?
Сколько у вас один инстанс браузера потребляет CPU и RAM?
Запускаете в обычном режиме или в headless? Большая разница по CPU и RAM?
Стабильность тестов выросла после перехода с Selenium Webdriver на Playwright? Если да, то насколько?
Selenoid не поддерживает Playwright. Хватает ли Вам параллельных потоков при прогоне тестов? Что будете делать при масштабировании? Ведь при запуске огромного количества тестов на одной виртуалке из-за создания множества контекстов, наверняка, тесты могут быть флаки в моменты пиковой нагрузки на CPU.
Какими инструментами тестируете API?
Спасибо за интерес к статье и крутые вопросы!
1. Запускаем тесты в 10 потоков, пользуемся встроенной в CodeceptJS фичей. Автотесты у нас атомарные, все завелось очень просто.
2. Сколько один инстанс браузера потребляет сильно зависит от того, что там вертится: посмотрел сейчас — увидел один хром, который использует до 140% одного CPU и порядка 400MB RAM. Количество воркеров лучше всего подтюнить по факту, мы пробовали гонять в разное количество потоков. На нашем железе и на нашем проекте оптимальней всего получилось 10.
3. Тут подход у нас простой, пишем тесты локально в headful-режиме, а в CI гоняем headless, там нам интерфейс ни к чему. Разницу между ними не замеряли.
4. Не могу дать точные цифры, потому что набора одинаковых тестов на 2-х инструментах у нас не было. Точно могу сказать, что стабильность повысилась за счет встроенных ожиданий самого Playwright. Также мы получили возможность добавить осознанности в наши автотесты, за счет доступа ко всем запросам. Например, мы часто ожидаем успешный ответ от бекенда, прежде чем начинать следующий шаг, делать это очень просто. PS: Пользуясь этим подходом, мы также проверяем отправку аналитики, если интересно, то скоро расскажу об этом подробнее здесь.
5. Selenoid довольно сильно нас выручил, когда мы использовали Webdriver, сейчас необходимость в нем пропала. С ростом количества тестов действительно возникает такой вопрос, даже больше скажу, текущие 30 минут для нас тоже много. Скорее всего, сейчас двинемся в сторону импакт-анализа, для более "умной" выборки тестов. Уже есть пара прототипов: как топорный — в виде парсинга коммита и попытки угадать затронутый функционал, так и более дорогой — в виде самописных анализаторов кода.
6. Мы используем Behat для тестов на API и Swagger для документирования. Кстати, недавно прикрутили к Behat-тестам отчет Allure, но пока не выгружаем их в TMS. Одна из задачек на будущее — добавить возможность запуска тестов через Allure TestOps по любой выборке (например, по конкретному эндпоинту) для всех слоев автотестов (в том числе, и UI-тестов на мобилках).
Понравился стиль изложения автора
Спасибо за статью! Скажите, а для чего вам CodeceptJS? Почему бы не использовать сам playwright с их собственным ранером?
Когда выбирали инструмент, playwright вообще не существовал еще. А у CodeceptJS конкурентов можно сказать и не было, все другие фреймворки на JS скорее заточены под unit-тестирование (jest, mocha, ava и т.д.).
Но на новом проекте как раз использовали тестраннер от playwright, он хорош, все задачи выполняет из коробки (вплоть до поддержки allure). Текущие автотесты переписывать уже не стоит, но в новых проектах будем использовать его.
Путь к автоматизации тестирования в SuperJob: инструменты, проблемы и решения