Прежде всего, я не рекомендую использовать shallow
в ваших тестах, а здесь - отличная статья, почему.
Я также рекомендую проверить реагирующее тестирование -library вместо энзима, так как его гораздо приятнее использовать.
Теперь ответим на ваш вопрос. Здесь вы используете хуки для redux
и react-router
, поэтому вам нужно предоставить необходимые данные тестируемому компоненту, чтобы он мог использовать эти хуки. Позвольте мне показать вам пример теста (который проверяет текст в элементе h2
):
import React from 'react';
import { mount } from 'enzyme';
import {Provider} from 'react-redux';
import {MemoryRouter, Route} from 'react-router';
import LoginForm from './LoginForm';
describe('Login Form', () => {
it('should have SIGN IN header', () => {
const store = createStore();
const component = mount(
<Provider store={store}>
<MemoryRouter initialEntries={['/login']}>
<Route path="/:botId" component={LoginForm} />
</MemoryRouter>
</Provider>
)
expect(component.find('h2').text()).toEqual('SIGN IN');
});
});
Некоторые пояснения к этому примеру.
- Я использую
mount
вместо shallow
, так как я предпочитаю как можно больше визуализировать в своем тесте, чтобы я мог проверить, все ли работает вместе, как и должно. - Вы видите, что я не визуализирую свой компонент напрямую, а вместо этого он обернут другими компонентами (
Provider
из react-redux
и MemoryRouter
из react-router
). Почему? Потому что мне нужно предоставить context моему компоненту. В этом случае это контекст redux
и router
, поэтому данные, используемые внутри, существуют и могут быть найдены (например, useSelector(state => state.auth)
должен иметь определенное состояние, чтобы иметь доступ к свойству auth
). Если вы удалите какой-либо из них, вы получите сообщение об ошибке, говорящее об отсутствии этого контекста - впереди go и проверьте сами:). - См. здесь , чтобы узнать подробнее о тестировании с
router
context - Что касается тестирования с
redux
, в моем примере есть функция createStore
, которую я не определил, поскольку есть несколько подходов к этому. Один включает создание реального магазина, который вы используете в своем производственном приложении. Это тот, который я предпочитаю, и мой коллега написал отличную статью на эту тему c здесь . Другое - создать какой-то фиктивный магазин, как в этой статье . Опять же, я предпочитаю первый подход, но какой из них лучше для вас.
Отвечая на другой вопрос о том, что вы должны проверить в этом примере. Есть несколько возможностей. Все зависит, главным образом, от вашего бизнес-кейса, но примеры, которые я бы здесь протестировал, включают:
- Ввод чего-то во ввод, нажатие кнопки и наблюдение за успешным входом в систему (путем перенаправления на новый путь -
/
в данном случае) - без ввода пароля и нажатия кнопки - должна отображаться ошибка
- Проверка, изменяется ли класс кнопки при загрузке
- Не отправлять действие входа дважды, когда уже загружается
И так далее ...
Это действительно только верхушка айсберга в том, что можно написать о тестировании, но я надеюсь, что это поможет и даст вам хорошее начало копать глубже в топи c.