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

мне нужно протестить взаимодействие хука с компонентом, не сам хук. Хук это вообще либа

тоже в компоненте

Зачем для этого мокать хук?

либо мокай данные которые примет компонент

просто если тебе надо кастомный хук протестить то только в компоненте

[ref, inView] = useInView();
Это обертка над IntersectionObserver. Мне надо протестить попадание компонента  в inView

Я бы предложил мокать не хук, а тригерить в тесте ивент intersection observer'а и дать этому хуку просто правильно на него реагировать. Таким образом, если ты поменяешь один хук на другой, то тест всё равно будет актуален

Не, это уже слишком. А главное, такого просто не нужно делать. Я хочу честный юнит тест

Я не буду уговаривать, но "это уже слишком" (ничего в этом такого нет на самом деле) будет болле полезный, чем "честный юнит-тест" (в контексте реакт-компонентов мокать и писать "честные юнит-тесты" вообще бывает спорно).

А что в контексте реакта такого особенного?

Ну как раз то, что компоненты тесно взаимодействуют друг с другом, с хуками, где-то ещё со всякими редаксами и мидлварями и тестировать юнитами сами компоненты, вне зависимости от енвайрнмента и того дерева, что они рендерят имеет смысл только, если есть более полно-тестирующие интеграционные (а где граница между юнитом и интеграционным? А между интеграционным и e2e?).
У тебя может прекрасно проходить тест, что компонент вызывает нужный коллбек по клику и другой тест, что коллбек нужный передаётся, но посредине что-то идёт не так и функциональность не работает. Чем больше замокано, тем больше шансов, что тест будет зелёным, а что-то будет не работать

Ага. Но зачем тогда вообще юнит тесты писать? e2e дает максимум уверенности, значит писать только их нужно?

юнит-тесты хорошо работают для утильных функций, каких-то апи и тд.
e2e бывает долго раннятся (у нас эта проблема решена, тесты гоняются в лямбдах, поэтому да, мы предпочитаем как можно писать их), немножко дольше обратная связь, в том плане, что от самой ошибки до понимания, что именно сломалось чуть дольше путь.
Интеграционные (под ними я сейчас буду понимать тесты реакт-компонентов аля с enzyme в ноде с jsdom) – такой промежуточный вариант, в котором ты можешь кусочки функциональности тестировать отдельно, эмулируя user input и следя за сайд-эффектами, которые мы ожидаем (например, что-то в лог напишет) или выводом компонента (нажали на кнопку, компонент перерендерился и вывел что-то другое).
"юнит-тесты" для реакт-компонента, типа компонент принял пропы, срендерил другие компоненты с пропами на практике очень много и бестолку писать, пропускает много ошибок, тратит много сил. Тайпскрипт решает половину таких тестов "бесплатно"

У меня есть уже протестированая либа которая дает четкий контракт для взаимодействия. Мне нужно только протестить взаимоействие ее с моим компонентом. И этот тест можно написать за 30 секунд (но только не с хуками оказывается)

Bogdan на самом деле тебе нужно понять что ты хочешь протестить? компонент или хук? или связь между хуком и компонентом, отсюда уже и будет исходить сам процесс написания теста

третье

если третье то сделай просто тестовый компонент и импортни туда хук и компонент и тестируй его это будет самое простое

а дальше пиши уже интеграционный e2e

на webdriverIO к примеру