Когда выбирали инструмент, playwright вообще не существовал еще. А у CodeceptJS конкурентов можно сказать и не было, все другие фреймворки на JS скорее заточены под unit-тестирование (jest, mocha, ava и т.д.).
Но на новом проекте как раз использовали тестраннер от playwright, он хорош, все задачи выполняет из коробки (вплоть до поддержки allure). Текущие автотесты переписывать уже не стоит, но в новых проектах будем использовать его.
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-тестов на мобилках).
Когда выбирали инструмент, playwright вообще не существовал еще. А у CodeceptJS конкурентов можно сказать и не было, все другие фреймворки на JS скорее заточены под unit-тестирование (jest, mocha, ava и т.д.).
Но на новом проекте как раз использовали тестраннер от playwright, он хорош, все задачи выполняет из коробки (вплоть до поддержки allure). Текущие автотесты переписывать уже не стоит, но в новых проектах будем использовать его.
Спасибо за интерес к статье и крутые вопросы!
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-тестов на мобилках).