Если бы вы спросили меня за пару недель до этого о библиотеке для тестирования приложения ReactJs, я бы ответил Jest и Enzyme, но недавно я начал работать над React Hooks и пытался протестировать его с помощью Enzyme, но я обнаружил, что он все еще не полностью поддерживает React Hooks. Вот открытая проблема на GitHub

Почему React-testing-library

Я начал искать другую библиотеку для тестирования, которая лучше поддерживает хуки, и нашел React-testing-library Кента К. Доддса. Это даже рекомендуется командой React в своей официальной документации . Итак, я решил попробовать.

Преимущества использования React-testing-library

Работая с React-testing-library, вам нужно переосмыслить свои тестовые случаи. Это заставляет нас писать тестовые примеры так, как пользователь будет взаимодействовать с приложением.

  1. Нет необходимости настраивать или инициализировать. С Enzyme вам нужно настроить адаптер, чтобы он работал с React 16, но с React-testing-library в этом нет необходимости.
import Enzyme from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

Enzyme.configure({ adapter: new Adapter() });

2. Нет Shallow рендеринга

У него нет мелкого рендеринга. Он будет отображать все, это означает, что он дает нам ту же среду, что и в браузере. Enzyme также имеет mount API, который служит той же цели. Так что это не настоящее преимущество перед Enzyme

3. Не нужноforceUpdate

Если вы используете Enzyme с sinon и следите за какой-либо стрелочной функцией внутри компонента, вам придется принудительно обновить компонент.

it('should fire handleClick when button is clicked', () => {
    const wrapper = shallow(<Component {...props} />
    const stubbedHandler = sinon.stub(wrapper.instance(), 
         'handleClick');
    this.setProps({prop1: 'string'}); // OR   wrapper.forceUpdate();
    chai.assert.isTrue(stubbedEventHandler.calledOnce);
    stubbedEventHandler.restore()
}

С библиотекой тестирования React не нужно делать все. Вам просто нужно иметь дело с DOM

4. Как избежать деталей реализации

React-testing-library призывает вас избегать подробностей реализации вашего компонента, а сосредоточиться на том, чтобы ваши тесты давали вам уверенность, для которой они предназначены. Это делает ваш тест более удобным в обслуживании в долгосрочной перспективе. Например, Enzyme позволяет вам обновлять состояние и свойства компонента, что на самом деле не так, как пользователь собирается использовать ваше приложение.

5. Принуждение к написанию лучших тестовых случаев

React-testing-library побуждает нас писать более качественные компоненты, придерживаться специальных возможностей и семантического HTML. Он предлагает очень мало способов выбрать элемент dom по test-id, placeholder, aria, который вряд ли изменится при рефакторинге кода.

Это дает вам большую уверенность, чем селекторы на основе CSS и id.

Поэтому, когда я писал свои тестовые примеры, я понял, что мои элементы нелегко доступны, поэтому я вернулся к HTML, изменил его, чтобы он стал доступным. Это похоже на механизм обратной связи о вашем компоненте.

Пример кода

it('Planet Info open and close ', () => {
    const props = {
        searchPlanet: jest.fn(),
        history: {
            push: jest.fn()
        },
        searchInfo: { 
            success: true, 
            results: [{ name: 'name1', population: 10 }, { name: 'name2', population: 10 }, { name: 'name3', population: 100 }] 
       }
    }
    
    const { queryByText, getByText, container } =      render(<PlanetSearch.WrappedComponent store={store} {...props} />);
    const planetItem = getByText('name1');
    fireEvent.click(planetItem);
    let planetInfo = getByText('Planet Info');
    expect(planetInfo).toBeTruthy();
    // Close Planet Info
    const closeBtn = container.querySelector('button[class="close"]');
    fireEvent.click(closeBtn);
    planetInfo = queryByText('Planet Info');
    expect(planetInfo).toBeNull();
});

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

Вывод

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

Но за последние пару месяцев с React-testing-library это заставило меня больше думать с точки зрения пользователя при написании тестов, следуя лучшим практикам (Доступность, Селекторы).

Я продолжу изучать это в своих будущих проектах.

Если вы тоже работаете с React и еще не пробовали React-testing-library, стоит взглянуть на него.