Ну, вообще-то, у рефакторинга есть вполне четкое определение — изменение исходного кода без изменения внешнего поведения. Если в коде есть ошибки, он не работоспособный, до рефакторинга ещё далеко. Если «рефакторинг» приводит к изменению внешнего поведения, то это не рефакторинг. Рефакторинг должен приводить к улучшению читаемости кода, делать его более лёгким для понимания.
> Причина тут в том, что рефакторинг может приводить к существенному изменению кода. А это в свою очередь может изменить граничные условия, для учёта которых могут потребоваться дополнительные тесты.
Если граничные условия у вас определяются кодом, а не бизнес-требованиями, стоит задуматься — всё ли вы делаете правильно? Да и вообще, правильно ли понимаете, что такое «рефакторинг»?
Здесь уже замешан store. Зачем нам тестировать то, что уже протестировано? Т.е. заворачивать в dispatch объект, которые возвращает функция, а потом проверять, что он попал в store. Это и так ясно, так и работает Redux :)
Мы немного о разных вещах говорим. Я работаю по TDD, потому пишу тесты, чтобы написать код, но не наоборот, таким образом, мне нужен тест для того, чтобы написать простейший action creator. И наличие такого теста даёт уверенность в том, что экшн будет возвращаться нужный, в том, что завтра другой разработчик его не отрефакторит, сломав логику.
Здесь у вас уже не юнит тест, а интеграционный, с моками ответа сервера и вот этим вот всем. К тому же, внутри него целых два не связанных проверки, плюс ещё замешана логика внутри самой проверки. Три экспекта показывают два независимых теста. Первый про pending, второй про fulfilled. Должен быть ещё и третий тест, который покажет работу с ошибкой в API.
Более того, вы используете redux-promise-middleware и тестируете её работу, а не своего создателя экшена, так что, в данном случае достаточно было протестировать только то, что задиспатчился экшн с типом GET_RANDOM_NUMBER.
Redux — вполне себе уже устоявшееся явление, у меня язык не повернётся называть его молодёжным и уж, тем более, хайпом :)). К тому же, в статье нет никакой агрессии по отношению к другим технологиям, чего не скажешь про приверженцев Мобикса или вот тех, кого вы назвали в первом предложении.
Да, Redux требует (без RTK) написание большого количества бойлерплейтного кода, но, в то же время, даёт мощный контроль над тем, что происходит в приложении, а так же значительно упрощает написание тестов. У каждого свой путь, здорово, что есть множество альтернативных инструментов, каждый может выбрать то, что подходит ему больше всего.
То, что вы написали в конце, больше походит на BDD. И это очень полезная штука, когда описывается внешнее поведение системы. Но эти тесты не исключают модульные тесты. Через TDD и unit тесты мы постепенно приходим к тому, чтобы отработали вот эти интеграционные тесты. Каждый архитектурный слой нуждается в тестировании, одних лишь верхнеуровневых тестов не достаточно.
Это очень хорошее правило и даже рабочее, только здесь немного иная ситуация. Очень полезно понимать концепцию работы библиотеки, для того, чтобы использовать её по-полной. Таким образом, зная, как это работает изнутри, можно смело брать инструменты, которые упрощают жизнь разработчика. От обратного идти несколько сложнее.
Начнем с того, что я высказал своё мнение, я его никому не навязываю.
Сейчас сложно вспомнить, что именно, так как времени прошло достаточно много. Плюс, для того, чтобы квалифицированно высказываться о чем-то, нужно некоторое время плотно с этим поработать. Моё знакомство было поверхностным. Я в мобиксе не увидел сходу чего-то, чего нельзя сделать на обычных кастомных рекатовски хуках, например. Не понравилась концепция разнозненных микро-стоейтов, которые потенциально могу привести к циклическим зависимостям. Ну и я там не увидел Flux :)
На самом деле, просто попробовали обе, выбрали ту, которая лучше подошла под наши задачи. Дополнительно обмазали это всё дело кастомными матчерами для жести, стало совсем приятно.
Если у вас перевёрнутая пирамида тестирования, тогда конечно, e2e и интеграционные тесты — ваше всё. Я выбираю более стабильные и быстрые unit тесты.
Стор с локализацией, текстовые константы вообще не имеют никакого отношения к примеру. Я намеренно всё оставил так просто без всяческих усложнений, так как они бы просто увели в сторону от идеи статьи.
Что касается технологий — я не ставил целью показать самый писк моды во фронтенде. Инженерные практики вообще мало зависят от используемых инструментов. Синтаксис импортов/экспортов может поменяться, так же как и навыки писать качественный код следует развивать постоянно, не привязываясь к конкретному стеку. Привычку писать код по TDD нужно вырабатывать, нельзя просто так взять и начать. И перед этим нужно просто научиться писать тесты. Во фронтенд-разработке большинство просто боится (или просто не хотят) писать тестируемый код, в статье я показал, что это очень даже возможно.
Достаточно скоропалительный вывод вы делаете. Я пробовал, мне не понравилось :), но я не делаю из своих ощущений выводы на сколько хороша эта библиотека. Лично для меня она оказалась не удобной.
Спасибо за пример альтернативного подхода.
React testing library рендерит DOM, что несколько более накладно, чем получение JSON представления дерева. react-test-renderer закрывает все наши потребности, это удобная и достаточно быстрая библиотека.
Спасибо, дельное замечание. В статье я не стремился показать идеальную архитектуру приложения, а продемонстрировать преимущества, которые даёт Redux, как он повышает уверенность в конечном результате. В каждом конкретном случае следует выбирать инструмент, который лучше подходит для выполнения конкретной задачи.
Спасибо за содержательный комментарий :). Если вас не заботит качество создаваемого продукта, тогда ваш «модный» подход подойдёт гораздо лучше. А когда вас интересует простота развития и поддержки продукта, снижение количества багов, то добро пожаловать в волшебный мир TDD
Замечу, что с развитием навыка написания тестов, скорость разработки не только не снижается, а даже ещё и повышается.
На самом деле, всё просто. Когда проект зарождался, MobX не было, а Redux уже был. Казалось бы, они оба про состояние, но подход у каждого совершенно отличается от другого. Каждому применение найдется.
Я не обладаю компетенциями по MobX, потому не могу прикинуть, на сколько удобно с ним работать и тестировать приложения.
Ох, камент через год ??
Да, вполне вероятно, ещё что-то будет. Черновики есть, но никак не оформятся пока что.
На Хабр Карьере по слову Redux выдается 88 вакансий, по MobX 19. Pascal и Fortran, действительно, по нулям.
У меня всё.
Просто оставлю ссылочку refactoring.com
Если граничные условия у вас определяются кодом, а не бизнес-требованиями, стоит задуматься — всё ли вы делаете правильно? Да и вообще, правильно ли понимаете, что такое «рефакторинг»?
Здесь у вас уже не юнит тест, а интеграционный, с моками ответа сервера и вот этим вот всем. К тому же, внутри него целых два не связанных проверки, плюс ещё замешана логика внутри самой проверки. Три экспекта показывают два независимых теста. Первый про pending, второй про fulfilled. Должен быть ещё и третий тест, который покажет работу с ошибкой в API.
Более того, вы используете redux-promise-middleware и тестируете её работу, а не своего создателя экшена, так что, в данном случае достаточно было протестировать только то, что задиспатчился экшн с типом GET_RANDOM_NUMBER.
Да, Redux требует (без RTK) написание большого количества бойлерплейтного кода, но, в то же время, даёт мощный контроль над тем, что происходит в приложении, а так же значительно упрощает написание тестов. У каждого свой путь, здорово, что есть множество альтернативных инструментов, каждый может выбрать то, что подходит ему больше всего.
Сейчас сложно вспомнить, что именно, так как времени прошло достаточно много. Плюс, для того, чтобы квалифицированно высказываться о чем-то, нужно некоторое время плотно с этим поработать. Моё знакомство было поверхностным. Я в мобиксе не увидел сходу чего-то, чего нельзя сделать на обычных кастомных рекатовски хуках, например. Не понравилась концепция разнозненных микро-стоейтов, которые потенциально могу привести к циклическим зависимостям. Ну и я там не увидел Flux :)
Стор с локализацией, текстовые константы вообще не имеют никакого отношения к примеру. Я намеренно всё оставил так просто без всяческих усложнений, так как они бы просто увели в сторону от идеи статьи.
Что касается технологий — я не ставил целью показать самый писк моды во фронтенде. Инженерные практики вообще мало зависят от используемых инструментов. Синтаксис импортов/экспортов может поменяться, так же как и навыки писать качественный код следует развивать постоянно, не привязываясь к конкретному стеку. Привычку писать код по TDD нужно вырабатывать, нельзя просто так взять и начать. И перед этим нужно просто научиться писать тесты. Во фронтенд-разработке большинство просто боится (или просто не хотят) писать тестируемый код, в статье я показал, что это очень даже возможно.
React testing library рендерит DOM, что несколько более накладно, чем получение JSON представления дерева. react-test-renderer закрывает все наши потребности, это удобная и достаточно быстрая библиотека.
Замечу, что с развитием навыка написания тестов, скорость разработки не только не снижается, а даже ещё и повышается.
Я не обладаю компетенциями по MobX, потому не могу прикинуть, на сколько удобно с ним работать и тестировать приложения.