Недавно я присоединился к довольно крупному банковскому проекту с компанией, в которой я пообещал себе, что больше никогда не буду работать. Я человек слова, но на этот раз денег было больше, чем ожидалось, и эта роль дала мне возможность немного больше контролировать качество продукта. Да, вы правы, я немного помешан на контроле и ненавижу, когда качество уступает место количеству.

Вернемся к моей теме обсуждения - в этом проекте 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 выглядит таким чистым: вся эта сложность, связанная с проверкой того, что что-то рендерится и все ли правильные реквизиты были переданы, исчезла.

В мгновение ока возникала проблема: каждый раз, когда кто-то добавлял новый класс или немного менял порядок в структуре компонентов, тесты терпели неудачу, потому что, конечно, снимки не совпадали, и нам приходилось обновляйте их снова и снова. И это заняло время. И это было скучно. Эти частые изменения характерны для каждого проекта, потому что иногда даже бриф не доработан, и мы не знаем, как будет выглядеть структура страницы, или иногда дизайн еще не готов, и нам нужно добавить новый класс в компонент. структура. Но я действительно не хочу тестировать такие вещи (классы, порядок структуры) - меня просто интересует логика компонента. Если нам это действительно нужно, решением может быть визуальное регрессионное тестирование, но, по моему скромному мнению, однозначно не модульное тестирование. Вот почему я думаю, что лучшим решением остается протестировать рендеринг, как я это сделал в первом примере. Это не потребует никаких обновлений, если появятся небольшие изменения, подобные описанному ранее.

Если у вас есть какие-либо другие предложения, мысли или мнения, не стесняйтесь комментировать, поскольку я открыт для обсуждения.