Хорошая ли идея протестировать redux store?

#reactjs #redux #react-redux #jestjs

#reactjs #redux #реагировать-redux #jestjs

Вопрос:

Проект, над которым я работаю, написан по такому шаблону: каждый компонент имеет index.js с помощью redux-сопоставлений и page.js который принимает сопоставления через props и отображает представление.

Компонент может быть огромным, он может содержать длинные цепочки других более мелких компонентов. Представьте, как каждый компонент в цепочке принимает около 30 реквизитов — данные redux и действия redux — и затем передает их в другие компоненты по цепочке, другие компоненты передают их в другие компоненты.

Хотя это очень типичная ситуация с redux, я не могу с этим смириться и все время пытаюсь ее избежать. Я пытаюсь использовать useSelector и useDispatch для работы с store, вместо передачи десятков свойств я добавляю useSelector прямо в то место, где нужны данные.

И, кажется, все в порядке, кроме тестов.

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

Такое ощущение, что я единственный человек, который пытается писать тесты, используя redux store. Это хорошая идея или плохая? Знаете ли вы несколько статей о том, как одновременно использовать useSelector и useDispatch и писать тесты?

Ответ №1:

Для удобства тестирования ознакомьтесь с шаблоном компонента контейнера и презентации. Что вы в основном делаете, так это создаете компонент, который является чисто презентационным и не поддерживает практически никакого состояния. Все, что он отображает, он получит через props. Это позволит вам протестировать визуальные элементы, не беспокоясь о хранилище.

Затем создайте компонент контейнера, который выполняет все операции redux, например, выборку, отправку и т.д., И он передаст соответствующее состояние в качестве реквизита презентационному компоненту. Это позволит контролировать размер вашего тестового файла и сфокусировать ваши тесты на разных целях, при этом делая их намного проще. Итак, ваш каталог будет выглядеть примерно так,

coolComponent

  • coolComponent.js (презентационный компонент)
  • coolComponent.test.js
  • index.js (компонент контейнера)
  • index.test.js

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

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

Комментарии:

1. К вашему сведению, это не шаблон компонента более высокого порядка, а скорее шаблон компонента контейнера и презентации ( иногда называемый умными и немыми компонентами ). HOC — это функции, которые используют компонент и возвращают (предположительно расширенный) компонент, тогда как контейнерный компонент просто переносит и передает данные в реквизит презентационного компонента, т. Е. это просто компоненты-оболочки. medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

2. @DrewReese Я всегда думал об этом в терминах функций. Поскольку он возвращает компонент (функцию), он будет считаться исправным. Спасибо за разъяснение. Теперь я должен пойти извиниться перед всеми, кого я знаю, за то, что сказал им не то. 🙂

3. Но я сказал, что проект уже использует этот шаблон в первом предложении вопроса, или мое первое предложение было не совсем чистым? Проблема, с которой я столкнулся с этим шаблоном, заключается в том, что контейнер передал около 30 реквизитов в презентационный компонент, этот презентационный компонент передал все или почти все эти реквизиты рядом с дочерними компонентами, которые также хотят работать с store. И в проекте есть десятки таких компонентов. Итак, это правильная архитектура redux, и нам просто нужно смириться с этим, когда проект использует redux.

4. @user2541867 это не очевидно. Вы можете поместить весь код в один файл, назвать его index и использовать redux вместе с ним.