Вообще, jest вижу на сегодня почти как стандарт в индустрии юнит тестирования. Не обязательно его использовать с react. Плюсы - отличная документация, большие возможности Минусы - слишком жирный 🙂 тесты запускаются медленно, но прогоняются быстро. Конкретно в данный момент, пишу тесты на jest для работы с датами (у нас legacy библиотека, известная всем кто работал с датами - moment). пример теста: describe(Group by ${GroupByPeriod.DAY}, () => { it(dayOfYear 68 (2021-03-09), () => { const pickerRange = { startsAtUTC: '2021-03-08T21:00:00.000Z', endsAtUTC: '2021-05-05T20:59:59.999Z', }; const p = { ...params, payload: { employeeId: 'employee-1', period: GroupByPeriod.DAY, startsAt: '2021-03-09', ...pickerRange, }, }; const expected = { employeeId: p.payload.employeeId, startsAtForDict: p.payload.startsAt, startsAt: pickerRange.startsAtUTC, endsAt: '2021-03-09T20:59:59.999Z', }; expect(makeStartEndDatesWithTimeZone(p)).toEqual(expected); }); }); Как видите, никакого "реакта" тут нет. Все тесты всегда сводятся к тому, что мы запустили настоящую функцию (в моем случае makeStartEndDatesWithTimeZone) и ждем ожидание (expected). Если вы не пишите юнит-тесты, то я очень советую разобраться. Так как научиться недолго, а времени экономит уйму. Причем не только вам, но и вашим коллегам. если перевести на русский, в тесте выше я проверяю, что дата старта и дата окончания, то что я ожидаю. --- Итого: Разница между тестом expect(add(1,3)).toBe(4) (якобы тестируем функцию сумма (add)) и портянкой выше, лишь в том, что у меня "ожидание" расписано в несколько строк. Отсюда можно сделать вывод, что сам по себе юнит-тест, это легкая конструкция. Обычно все проблемы только с первичной настройкой.