Pull to refresh

Comments 8

Не очень понял зачем все это придумано. Почему нельзя использовать подход rtl? Вы все равно создаете стор, так почему тогда не тестировать его в том виде в котором он будет использоваться?

Вы предлагаете тестирование приложения с точки зрения пользователя, я не против. Но когда хотят функциональное тестирование, то приходят на выручку данные решения. react testing library это больше про интеграционные тесты.

Вы что подразумеваете под "функциональном тестировании"? Тестирование функциональных возможностей приложения? Тогда это rtl. Тестирование реализации выполненной в виде функций? Тогда подход rtl говорит, что лучше этого не делать.
Тестирование библиотечной функциональности выраженной в библиотечных функциях и наборов классов? Тогда у вас неверно подобраны примеры.

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

Просто для примера, почему бы тогда не мокать экшены на уровне модулей? Да и в целом, зачем вообще их проверять, если нас интересует только конечное состояние?

Со стороны, очень похоже на какое-то логирование шагов операций. А это уже антишаблон. Так делать не нужно.

Пример взят из потолка. Реальный пример под который создавалось данное решение - тестирование middleware.

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

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

Что-то я запутался. Вы пишете:

"Цель этой статьи в том, чтобы показать как тестировать action в redux store. "

и уже в конце статьи:

Это демонстрация того, что redux можно и нужно тестировать.

Но теперь говорите, что суть была тестировать мидлваре?

А почему просто не взять и не протестировать эту мидварю не подключая к стору? Вы все равно тестируете внутреннею реализацию.

А если боитесь напутать с созданием мидлваре, то видимо стоит явно задать тип actionsMiddleware ?

И в догонку с функциональность toHaveElementInArray справляется toContainEqual

Надо было проверить как ведет себя хранилище, как меняются состояния, что происходит с приложением, когда отрабатывает Middleware.

toContainEqual - отличное решение, не знал о нем.

Sign up to leave a comment.

Articles