Полагаю, вам не нужно проверять, как выглядят внутренние обработчики событий.Возможно, вас заинтересуют разные вещи: если запускающий обработчик событий меняет компонент так, как вы ожидаете (.toMatchSnapshot()
здесь намного лучше, чем тестирование структуры вручную с помощью .toHaveLength
), и если обратный вызов, который вы прошли через props
, вызывается придолжен (.toHaveBeenCalled
).Что, если компонент когда-нибудь будет изменен, чтобы не просто вызывать .props.filterByNeedsReviewFn()
, но и делать что-то вроде вызова чего-то еще?должен ли ваш тест провалиться только потому, что где-то внутри передан именованный метод?Я считаю, что это не так.
Так что я вижу, что ваш тест будет
it('renders a filter tab with expected props after clicking', () => {
const comp = shallowRender({});
comp.find(FilterTab).simulate('click');
expect(comp).toMatchSnapshot();
});
it('calls callback passed after clicking on filter tab', () => {
const filterByNeedsReviewFn = jest.fn()
const comp = shallowRender({ filterByNeedsReviewFn });
comp.find(FilterTab).simulate('click');
// let's ensure callback has been called without any unexpected arguments
expect(filterByNeedsReviewFn ).toHaveBeenCalledWith();
});
Я не думаю, что вам на самом деле нужен этот код, но я хотел показать, насколько ясным может быть такой подход.У вашего компонента есть API: он поддерживает обратный вызов и вызывает вывод.Таким образом, мы можем пропустить внутреннее тестирование без каких-либо ошибок