Недавно я присоединился к довольно крупному банковскому проекту с компанией, в которой я пообещал себе, что больше никогда не буду работать. Я человек слова, но на этот раз денег было больше, чем ожидалось, и эта роль дала мне возможность немного больше контролировать качество продукта. Да, вы правы, я немного помешан на контроле и ненавижу, когда качество уступает место количеству.
Вернемся к моей теме обсуждения - в этом проекте Jest используется в качестве инструмента для модульного тестирования. Хотя это было не мое решение, я был весьма удивлен, как этот инструмент изменился за последние два года. Я впервые использовал Jest два года назад, и тогда он был довольно медленным, требовалось много времени, чтобы начать выполнение тестов. После завершения проекта я бросил его и вернулся к своему любимому набору инструментов: мокко, чай, синон.
Но Jest сейчас совсем не плох, поскольку производительность значительно улучшилась, и мне просто нравится все в одном пакете. Более того, тестирование снимков показалось просто отличным.
Чтобы заметить разницу, я просто хочу поделиться некоторым кодом о том, как я тестировал рендеринг реагирующего компонента с помощью мокко и как его можно протестировать с помощью Jest.
Версия мокко:
describe('render', () => { it('should render an Whatever child component', () => { const renderOutput = shallow(<Component {...props} />); const child = wrapper.find(Whatever); expect(child.length).to.equal(1); }); it('should render an AnotherWhatever component if loaded property value is true', () => { const props = { someProp: 'some value', anotherProp: 1}; let renderOutput = shallow( <Component loaded={false} {...props} /> ); let child = wrapper.find(AnotherWhatever); expect(child.length).to.equal(0); renderOutput = shallow(<Component loaded {...props} />); child = wrapper.find(AnotherWhatever); expect(child.length).to.equal(1); const childProps = child.props(); expect(childProps.loaded).to.equal(true); expect(props.someProp).to.equal(props.someProp); expect(props.anotherProp).to.equal(props.anotherProp); }); });
Версия снимка Jest:
describe('render', () => { it('should render as expected', () => { const renderOutput = renderer.create(<Component {...props} />); expect(wrapper.toJSON()).toMatchSnapshot(); }); it('should render as expected if loaded property value is false', () => { const renderOutput = renderer.create( <Component loaded={false} {...props} /> ); expect(wrapper.toJSON()).toMatchSnapshot(); }); it('should render as expected if loaded property value is true', () => { const renderOutput = renderer.create( <Component loaded {...props} /> ); expect(wrapper.toJSON()).toMatchSnapshot(); }); });
Как видите, пример снимка Jest выглядит таким чистым: вся эта сложность, связанная с проверкой того, что что-то рендерится и все ли правильные реквизиты были переданы, исчезла.
В мгновение ока возникала проблема: каждый раз, когда кто-то добавлял новый класс или немного менял порядок в структуре компонентов, тесты терпели неудачу, потому что, конечно, снимки не совпадали, и нам приходилось обновляйте их снова и снова. И это заняло время. И это было скучно. Эти частые изменения характерны для каждого проекта, потому что иногда даже бриф не доработан, и мы не знаем, как будет выглядеть структура страницы, или иногда дизайн еще не готов, и нам нужно добавить новый класс в компонент. структура. Но я действительно не хочу тестировать такие вещи (классы, порядок структуры) - меня просто интересует логика компонента. Если нам это действительно нужно, решением может быть визуальное регрессионное тестирование, но, по моему скромному мнению, однозначно не модульное тестирование. Вот почему я думаю, что лучшим решением остается протестировать рендеринг, как я это сделал в первом примере. Это не потребует никаких обновлений, если появятся небольшие изменения, подобные описанному ранее.
Если у вас есть какие-либо другие предложения, мысли или мнения, не стесняйтесь комментировать, поскольку я открыт для обсуждения.