Comments 4
Авторы reselect предлагают тестировать комбайнер функцию, в случае, если зависимости сложные: github.com/reduxjs/reselect#q-how-do-i-test-a-selector
Ваш подход не плох.
Но, ИМХО:
1. Про TDD можно забыть
2. Сложно будет поддерживать такие тесты
3. В сложном приложении будут проблемы с тестированием экзотических кейсов
Ваш подход не плох.
Но, ИМХО:
1. Про TDD можно забыть
2. Сложно будет поддерживать такие тесты
3. В сложном приложении будут проблемы с тестированием экзотических кейсов
Всё верно, данный подход не совместим с идеей TDD. Про поддержку я уже думаю, вероятно функционал будет расширен и можно будет обновить тесты прямо из CLI, если добавились новые поля в стор, или поменялись результаты селекторов.
Касательно экзотических кейсов, вы имеете в виду, что сложно в браузере воспроизвести такой кейс?
Касательно экзотических кейсов, вы имеете в виду, что сложно в браузере воспроизвести такой кейс?
Да, возможны кейсы, когда на локальном энвайронменте какие-то кейсы могут быть недоступны для воспроизведения. Они могут требовать специфичных ответов от бэкенда и тд.
В данном случае — да. Не возможно (или неоправданно сложно) протестировать поведение, которое не воспроизводится локально или на тестовом окружении. В целом и разработка таких систем затрудняется той-же причиной.
Помню, как работая над внутренним приложением одного из крупнейших российских банков — приходилось переносить системный блок в другую часть здания, чтобы попасть в нужную подсеть и получить нужный ответ от сервиса.
Вероятно, можно будет подумать и над решением этой проблемы, в дальнейшем…
Помню, как работая над внутренним приложением одного из крупнейших российских банков — приходилось переносить системный блок в другую часть здания, чтобы попасть в нужную подсеть и получить нужный ответ от сервиса.
Вероятно, можно будет подумать и над решением этой проблемы, в дальнейшем…
Sign up to leave a comment.
Автоматизируем тестирование redux селекторов в приложении