(спешу заметить что в примерах мокаются не хуки Реакта)

Потому что то что в хуках – часть логики компонента. Хук обновился, мок нет. Тест зелёный, а компонент не работает

То что в хуках — логика хука) По твоим словам моки это вообще плохая практика

Если у хука поменялась сигнатура — это другое дело. Но такую проблему можно придумать для любых юнит тестов. И компоненты и хуки это всего лишь функции

> моки это вообще плохая практика

в общем случае, их лучше делать меньше, чем больше.

> То что в хуках — логика хука) По твоим словам

Ну "по твоим словам" можно замокать любые функции, которые внутри компонента используются, ведь это их логика, что останется 🙂

В любом случае, я сказал, что практика спорная, а не "ни в коем случае так делать не стоит")

> Ну "по твоим словам" можно замокать любые функции, которые внутри компонента используются, ведь это их логика, что останется

Так работает юнит тестирование. Модуль А использует модуль Б. Я тестирую модуль А, значит мне нужен полный контроль над модулем Б. Я мокаю модуль Б, чтобы 1) не было сайд эффектов 2) чтобы программно переводить его в нужные для тестов модуля А состояния. Так это работает для юнит тестирования любых форм кода

Не уверен, зачем нужен полный контроль над модулем Б. Когда-то тут уже приводил этот пример. Есть функция

import {add2, add3} from 'useful-lib';

function add5(a) {
  return add3(add2(a));
}

Я ожидаю, что функия add5(3) вернёт 8, в тестах предложите мокать add2 и add3? Тогда тест функции add5 станет бесполезным, так как внутри всё замокано.
Потом я перепишу add3 на a => a + 7, но он останется замоканым в тесте функции add5, тест будет зелёным, а по факту add5(3) будет возвращать 12

Потому что add3 и add2 – это детали реализации функции add5

Так же, как и хук для компонента, который просто функция.

По поводу сайд-эффектов, как правило у компонента есть ожидаемые сайд-эффекты, которые мы в тесте тоже хотим протестировать

Могу я тебя попросить придумать пример получше?

Если тебе нужно чтобы тесты реагировали изменения в композиции модулей — это называется интеграционное тестирование

🙂 спроси 10 девелоперов определения и границы между юнит-тестированием, интеграционным и e2e, получишь 10 разных ответов

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

этот чел примерно такое и говорит http://kentcdodds.com )

Ребят а не у кого не завалялось тулзы или либки для подписывания экшенов в стиле Flux аля (SUCCESS, FAILED, ERROR, FETCH). Может есть более изящные решения?

что такое подписывание экшенов?

впринципе уже разобрались, есть пару идей. Ну это аля у тебя есть функа которая создает экшен в асинхронном стиле и добовляет _FETCH, _SUCCESS, _ERROR