Jest-тестирование компонентов класса React

Question

Я изо всех сил пытаюсь найти четкое объяснение того, как использовать jest для проверки компонента класса реакции. Я хочу добавить модульный тест в функцию onSubmit формы создания.

handleCreateHouse(e) {
        store.dispatch(createHouseDraft(this.state.house)).then(() => {
            if (!this.props.creation_error) {
                if (this.props.house.id) {
                    for (let key in this.floors) {
                        if (this.floors[key]) {
                            store.dispatch(createFloorDraft({ 'name': this.floors[key], 'house_id': this.props.house.id }))
                                .catch(err => console.log(err));
                        }
                    }
                }
            } else {
                switch (this.props.creation_error.code) {
                    case "duplicated_rif": {
                        this.setState({
                            ...this.state,
                            errors: {
                                ...this.state.errors,
                                ref: true
                            }
                        })
                    }
                }
            }
        }).then(() => store.dispatch(fetchHouseDraftList(this.state)))
        .then(() => this.props.onAddHouse())
        .catch(err => console.log(err));
    } 

Answer 1

Поскольку вопрос очень широкий, я попытаюсь сформулировать общую идею демистификации компонентов и тестирования. Компоненты класса React находятся на очень простом c уровне уровня JavaScript классов. Так, например, вы можете протестировать их так же, как вы тестировали бы класс:

class MyComponent extends React.Component {
  handleCreateHouse(event) {
    this.setState({ clicked: true });
  }
}

const component = new MyComponent();
const setStateMock = jest.fn();
component.setState = setStateMock;
component.handleCreateHouse();
expect(setStateMock).toHaveBeenCalled();

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

1. использовать тестовый компонент-рендеринг, такой как энзим или библиотека реагирующих тестов . Может быть много других, поэтому я оставляю вам исследование.

Эти модули предоставляют способ создания экземпляра компонента и предоставляют API вокруг этого компонента, который напоминает функции, подобные функциям обычного DOM. Таким образом, вы можете инициировать изменение состояния или щелчок по элементу, проверять, не были ли вызваны различные макеты, или, возможно, даже проверять изменения состояния.

Попытайтесь учесть обратные вызовы, чтобы иметь как можно больше кода без сохранения состояния: в приведенном вами примере, если вы игнорируете установщик доступа this.state, большая часть кода представляет собой logi c, который можно протестировать без на самом деле настройка жгута компонентов. Затем это становится похожим на пример, который я показал выше.

---

Другая область путаницы может возникнуть с store. Это похоже на волшебный c объект, который доступен в контексте функции. Непонятно, откуда исходит объект - я предполагаю, что хранилище создается в том же файле, в котором находится компонент, что, я бы сказал, немного нетрадиционно. Если это так, вы можете смоделировать реализацию магазина (но все же повторно использовать действия, которые есть в вашем приложении), используя redux-mock-store; эта библиотека используется в redux docs