а не надо 2000 браузеров поддерживть

обычно 2 последние версии + ie11 или без него

в общем берите все актуальные браузеры за 2018 год покрвающие 80% рынка и скорее всего они и будут покрывать те же 80% рынка и все

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

имел в виду, что тестировать в jest я для нас не вижу смысла

2 последние версии - это не совсем корректно у разных браузеров разное расписание выхода а устройства все бурут примерно в ожно время

лучше брать по стрезу времени

все верно, просто я отвечал на фразу про 2000

ну да естесственно

большинсво браузеров будут отличаться не версией а форм-фактором устройства

если насрать как будет выглядеть то и тестировать ненадо

в теории можно делать ribbon или respoinsive или adaptive ui

тогда соглашусь на 8 формфакторов основных в тз (и чтобы было прописаны размеры и соотношение сторон и ретина не нетина то есть dpi) и тогда норм

иначе заеьюююут а вот тут у начальника iphone 4s там в экранчик не влезает надпись

потому что ситуации разные бывают и надо фиксировать все кейсы детально потому что это выносит мозг - вся неопределенность с тестами

ну я бы сказал, что надо во всем меру знать
в теории ты все правильно говоришь, на практике ресурсов не хватает все так детально тестировать

но стараться надо 🙂

короче вы за e2e тесты для компонентов)

смотря что тестировать. у нас UI элементы и мы тестируем DOM, где могут быть различия между браузерами и иногда баги

если тестировать бизнес-логику, то наверное Jest будет достаточно

jest в данном случае не ограничивает нас, на нём можно и e2e писать, к примеру тот же stencil так и делат. Мне пока кажется разумно разделять на unit тесты, которые могут проверить API компонента, реакцию стейта на изменение атрибутов и т.д. (это можно сделать через Electron). А вот далее делать e2e тесты через Puppeteer или что-то подобное для других браузеров и вот уже там проверять правильность отображения в разных браузерах и взаимодействие с пользователем.