Comments 9
Автор, а вы смотрели на Karma: https://karma-runner.github.io/4.0/index.html
Там дается реальный браузер и возможность рендерить в нем свои компоненты в песочнице. И не нужно натягивать для этого инструменты, которые для этого не были приспособлены.
Cypress показался нашей команде настолько мощным, что мы полностью отказались от инструментов, использующих js-dom под капотом для тестирования UI-компонентов.
Интересно, как вы будете справляться когда число тесткейсов перевалит за тысячу. Браузерные тесты долгие, а параллелизация в Cypress дорогая. В прямом смысле, там нужен dashboard service, а он стоит денег для более-менее приличного количества тестов.
С другой стороны у нас основная библиотека содержит от силы 20 крупных компонентов, эти тесты проходят за минуту.
А проект содержащий на фронте 1000 переиспользуемых покрытых тестами компонентов еще поискать надо. Для такой махины денюшка за параллелизацию это капля в море. К тому же всё может окупится после первого крупного рефакторинга CSS (Я про встроенную в Cypress проверку возможности клика и ввода. Вроде мелочь, а как приятно).
Скажу больше, мы как-то прилично вложились в регресс по верстке страниц через снятие скриншотов — решили сэкономить. Расширяли Cypress через commands & plugins самостоятельно. Результат немного предсказуем — видеокарты рендерили по разному, скриншоты «дрожали», получение снимков и вычисления были медленными и работающего процесса из этого не вышло.
Погрустили-погрустили и согласовали закупку Chromatic.
1000 переиспользуемых компонентов
Звучит как страшный сон)
Если у вас есть хотя бы по 50 тестов на компонент, то в целом у вас и получится 1000 тестов. Как уместить их прохождение в одну минуту?
Конфиг:
i5-6500T 2.5ghz 4 ядра, 16 GB RAM, SSD
Замеры:
В настоящий момент имеем 264 тест-кейса на компонентах.
В среднем они выполняются примерно за 110 секунд (без учета холодного старта на 30 секунд).
Значит, 1000 тест-кейсов пройдут за 7 минут.
Как по мне, обычная цена за удобства. Если CI крутить не на пятилетнем процессоре с зарезанным тепловыделением, время будет еще лучше.
С т.з. разработки компонента по TDD скорость отличная.
Если есть аналогичные цифры на Karma, буду рад их узнать.
500 тестов выполняются за 20 секунд.
Но мы сейчас планируем переехать с Karma на JSDOM. Как показывает практика, нормальные юнит-тесты CSS-не требуют и в JSDOM их можно исполнять быстрее (и следовательно написать больше тестов). А визуальная часть проверяется веб-драйвером.
Как я понимаю, под веб-драйвером имеется ввиду Selenium или инструмент поверх него. Эти тесты пишет отдельная команда или вы выбрали этот инструмент и пользуетесь им сами? Какие цели преследуете?
Спрашиваю для общего развития. Очередной стек поресерчить дело благородное, но зачем, если можно спросить знающего человека?
Например по пути к Cypress я пробовал Jest, Enzyme. Так или иначе мы в команде не смогли ответить на вопрос зачем нам нужны именно юнит-тесты компонентов.
Мы посчитали, что тесты на компонентах должны показывать, что они работают в целом. В итоге мы сделали в упор в простоту написания, поддерживаемость и визуальное документирование возможностей.
Вдобавок к Cypress мы имеем Karma, но в ней чисто юниты крутятся (в основном это функции и чуть-чуть классов).
Эти тесты пишет отдельная команда или вы выбрали этот инструмент и пользуетесь им сами? Какие цели преследуете?
Сами пишем, на webdriver.io. Цель – протестировать компоненты "как будто от реального пользователя".
Мы посчитали, что тесты на компонентах должны показывать, что они работают в целом.
Ну JSDOM вам это и покажет. Вы же не используете element.getBoundingElementRect в каждом компоненте? Все примеры тестов из статьи, вроде "renders text field" прекрасно ложатся в JSDOM и отнимают в разы меньше времени на исполнение.
Cypress + Storybook. Хранение тестового сценария, данных и рендеринг компонента в одном месте