Блог

Я создал простой компонент react и написал тестовые примеры компонентов, которые работают правильно. У меня есть отчет о покрытии для тестовых примеров.

Теперь я добавил react redux в свой другой компонент. этот компонент содержит componentDidMount() и экспортировать методы default connect(null, updateProps)(ComponentName). Мне нужно написать модульные тестовые примеры для этих методов.

Пожалуйста, обратитесь к приведенному ниже образцу кода,

 class MyComponent extends Component {
       componentDidMount = () => {
          //some code here
      )

      handleSignIn = (e) => {
          //some code here
      }

      render() {
        return (
          <div>
             <form  onSubmit={this.handleSignIn}>
               <Input
                 type="text"
                 name="inputText"
                 placeholder="Text"
                 autoFocus
                 required
               />
            </form>
        </div>
      );
    }

    const updateProps = (dispatch) => {
      return {
        //some code here
      };
    };

    export default connect(null, updateProps)(MyComponent);
 

В вашем коде у вас есть две вещи:

 class MyComponent
 

и

 const thisIsBasicallyAnotherComponent = connect(null, updateProps)(MyComponent);
 

Итак, если вы хотите протестировать свой компонент, у вас в основном есть два варианта. Вы можете протестировать свой компонент, завернутый и подключенный к хранилищу redux, или вы можете написать простой модульный тест для вашего компонента класса как есть.

Что я бы рекомендовал сделать, так это экспортировать компонент вашего класса

 - class MyComponent extends Component { // replace this
  export class MyComponent extends Component { // with this
 

А затем вы можете протестировать свой компонент React с помощью Jest, как и любой другой компонент.

 test('Link changes the class when hovered', () => {
  const component = renderer.create(
    <MyComponent {...mockProps} /> // !! keep in mind that you have to manually pass what you have in `updateProps` because the component is not connected to Redux store anymore
  );

  // ... write your test and expectations here
});
 

В противном случае вы можете протестировать подключенный компонент (который экспортируется по умолчанию), но тогда вам придется обернуть компонент в Redux provider, чтобы протестировать его.

Вы можете найти более подробную информацию о тестировании здесь:

• Как тестировать компоненты
• Как протестировать подключенные компоненты

Вы можете использовать Provider from react-redux или redux-mock-store , чтобы избежать необходимости использовать real reducer:

 import { Provider } from 'react-redux';
import configureStore from 'redux-mock-store';
import MyComponent from './MyComponent.jsx';

const mockStore = configureStore([thunk]);

it('does something on mount', () => {
  // let's mock some Redux state
  const store = mockStore({ slice1: { id: 2, name: '11' } });
  mount(<Provider store={store}><MyComponent /></Provider>);
  expect(store.getActions()).toContainEqual({
    type: 'some-type',
    payload: ....
  });
});
 

Но это так просто только для простых действий. Что делать, если вы используете redux-thunk и происходит некоторая загрузка? Есть 2 способа:

1. Передать redux-thunk промежуточное mockStore программное обеспечение в сеть и имитировать ее, скажем, с помощью mock-fetch или nock . Проще настроить, но также это может быть излишним, если вы уже тестируете свой Redux напрямую, повторяя тесты для «ошибка загрузки», «загрузка занимает много времени» и т. Д. Также Для вашего компонента будет означать двойную работу.
2. Вы можете издеваться, ../yourPath/actions.js чтобы каждое действие было простым объектом, а не куском. Обычно я иду этим путем.

Но как насчет «экспорта развернутого компонента, чтобы мы могли тестировать компонент изолированно, без Redux»? Видите ли, он работал, когда connect был единственным возможным API. Но теперь, имея useSelector useDispatch useStore в виду такие хукеры, как , , гораздо надежнее сначала выполнить тесты для «моего компонента В Redux». В противном случае при подходе «двойного экспорта» мы можем обнаружить, что преобразование компонента из класса в функцию означает гораздо больше работы над исправлением тестов, а не над самим компонентом.