Как стать автором
Обновить

Комментарии 10

Тем не менее, по моим личным ощущениям

Личные ощущения — это ненадежная метрика. Может, все-таки, лучше привести цифры?

Честно говоря я не измерял diff по времени запуска тестов, но при переводе проекта с Mocha+Karma на Jest я и без замеров заметил, что мои тесты стали очень долго стартовать, тратя около 3 секунд минимум на старт, в то время как раньше это занимало менее секунды. К сожалению нет сейчас проекта на Karma+Mocha чтобы померить, но на github есть много примеров откуда можно почерпнуть цифры, например тут или вот тут.

Указанные тикеты закрыты больше года назад, сейчас ситуация кажется другой.


В этой статье Кристоф рассказывает, что именно они сделали, чтобы переломить ситуацию.

Во второй части в коде вы пишете такие строки


expect(renderedComponent.find('section').hasClass('home')).toBe(true);
expect(renderedComponent.find('h1').text()).toBe('Home');
expect(renderedComponent.find('input').length).toBe(1);

Эти конструкции повторяются из теста в тест. Гораздо лучше завернуть их в переиспользуемый объект


//в before
const component = new PageObject(renderedComponent);

//в тесте
expect(component.section().hasClass('home')).toBe(true);
expect(component.header().text()).toBe('Home');
expect(component.input().length).toBe(1);

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


Подробнее об этом подходе рассказывается здесь.

Да вы правы, код тестов не блещет красотой. У меня не было задачи написать крутые тесты, скорее я хотел показать, на примерах, как использовать инструменты. В продакш тестах мы конечно бы так не делали, а максимально использовали бы методы beforeAll и beforeEach. Например, я так делаю в тестах редьюсеров.
> Грубо говоря, первый раз вы запускаете тест, чтобы сформировать такой слепок, проверяете его валидность руками и коммитите его в репозиторий кода.

Не знаю, как у других, но мы столкнулись с тем, что люди не особо тщательно проверяют такие слепки, в итоге некорректные тесты.
Вообще получается какая-то инверсия, тест должен проверить что код написан верно, а по факту код и является автоматически сформированным доказательством.
В итоге, пока отношусь к слепкам скептически и осторожно.
Да, мы тоже напоролись на ленивую валидацию слепков разработчиками. И пока используем их с осторожность, скорее как дополнительную возможность проверки.
Вариант слепков удобен для ситуации 'Уже есть код, уже проверили тестировщики, надо зафиксировать состояние, имхо.'
Если данная тема будет интересна, то в следующих статьях мы попробуем серьезно протестировать более сложное приложение, использующее redux, redux-saga, react-intl, модальные окошки и прочие элементы, усложняющие тестирование.

Тема очень интересная, очевидно. Хотелось бы поскорее увидеть продолжение!

Жаль, что продолжения с перечисленными вкусностями — похоже не будет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий