Комментарии 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, модальные окошки и прочие элементы, усложняющие тестирование.
Тема очень интересная, очевидно. Хотелось бы поскорее увидеть продолжение!
Жаль, что продолжения с перечисленными вкусностями — похоже не будет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование в React