Как я понимаю, под веб-драйвером имеется ввиду Selenium или инструмент поверх него. Эти тесты пишет отдельная команда или вы выбрали этот инструмент и пользуетесь им сами? Какие цели преследуете?
Спрашиваю для общего развития. Очередной стек поресерчить дело благородное, но зачем, если можно спросить знающего человека?
Например по пути к Cypress я пробовал Jest, Enzyme. Так или иначе мы в команде не смогли ответить на вопрос зачем нам нужны именно юнит-тесты компонентов.
Мы посчитали, что тесты на компонентах должны показывать, что они работают в целом. В итоге мы сделали в упор в простоту написания, поддерживаемость и визуальное документирование возможностей.
Вдобавок к Cypress мы имеем Karma, но в ней чисто юниты крутятся (в основном это функции и чуть-чуть классов).
Конфиг:
i5-6500T 2.5ghz 4 ядра, 16 GB RAM, SSD
Замеры:
В настоящий момент имеем 264 тест-кейса на компонентах.
В среднем они выполняются примерно за 110 секунд (без учета холодного старта на 30 секунд).
Значит, 1000 тест-кейсов пройдут за 7 минут.
Как по мне, обычная цена за удобства. Если CI крутить не на пятилетнем процессоре с зарезанным тепловыделением, время будет еще лучше.
С т.з. разработки компонента по TDD скорость отличная.
Если есть аналогичные цифры на Karma, буду рад их узнать.
С другой стороны у нас основная библиотека содержит от силы 20 крупных компонентов, эти тесты проходят за минуту.
А проект содержащий на фронте 1000 переиспользуемых покрытых тестами компонентов еще поискать надо. Для такой махины денюшка за параллелизацию это капля в море. К тому же всё может окупится после первого крупного рефакторинга CSS (Я про встроенную в Cypress проверку возможности клика и ввода. Вроде мелочь, а как приятно).
Скажу больше, мы как-то прилично вложились в регресс по верстке страниц через снятие скриншотов — решили сэкономить. Расширяли Cypress через commands & plugins самостоятельно. Результат немного предсказуем — видеокарты рендерили по разному, скриншоты «дрожали», получение снимков и вычисления были медленными и работающего процесса из этого не вышло.
Погрустили-погрустили и согласовали закупку Chromatic.
Как я понимаю, под веб-драйвером имеется ввиду Selenium или инструмент поверх него. Эти тесты пишет отдельная команда или вы выбрали этот инструмент и пользуетесь им сами? Какие цели преследуете?
Спрашиваю для общего развития. Очередной стек поресерчить дело благородное, но зачем, если можно спросить знающего человека?
Например по пути к Cypress я пробовал Jest, Enzyme. Так или иначе мы в команде не смогли ответить на вопрос зачем нам нужны именно юнит-тесты компонентов.
Мы посчитали, что тесты на компонентах должны показывать, что они работают в целом. В итоге мы сделали в упор в простоту написания, поддерживаемость и визуальное документирование возможностей.
Вдобавок к Cypress мы имеем Karma, но в ней чисто юниты крутятся (в основном это функции и чуть-чуть классов).
Конфиг:
i5-6500T 2.5ghz 4 ядра, 16 GB RAM, SSD
Замеры:
В настоящий момент имеем 264 тест-кейса на компонентах.
В среднем они выполняются примерно за 110 секунд (без учета холодного старта на 30 секунд).
Значит, 1000 тест-кейсов пройдут за 7 минут.
Как по мне, обычная цена за удобства. Если CI крутить не на пятилетнем процессоре с зарезанным тепловыделением, время будет еще лучше.
С т.з. разработки компонента по TDD скорость отличная.
Если есть аналогичные цифры на Karma, буду рад их узнать.
С другой стороны у нас основная библиотека содержит от силы 20 крупных компонентов, эти тесты проходят за минуту.
А проект содержащий на фронте 1000 переиспользуемых покрытых тестами компонентов еще поискать надо. Для такой махины денюшка за параллелизацию это капля в море. К тому же всё может окупится после первого крупного рефакторинга CSS (Я про встроенную в Cypress проверку возможности клика и ввода. Вроде мелочь, а как приятно).
Скажу больше, мы как-то прилично вложились в регресс по верстке страниц через снятие скриншотов — решили сэкономить. Расширяли Cypress через commands & plugins самостоятельно. Результат немного предсказуем — видеокарты рендерили по разному, скриншоты «дрожали», получение снимков и вычисления были медленными и работающего процесса из этого не вышло.
Погрустили-погрустили и согласовали закупку Chromatic.