С бэкендом определились. Идем дальше по пирамиде тестирования.
⬇️
В основе пирамиды на мой взгляд должны стоять не Unit-тесты, а строгая типизация и строгие линтеры. Помимо стандартных ESlint-плагинов, типа react, react-hooks, jsx-a11y, node, promise, import и т.д., обратите внимание на:
github.com/SonarSource/es… и github.com/sindresorhus/e…
Готовые конфиги (типа eslint-config-airbnb) мне не нравятся тем, что они смешивают стилистические и логические правила. Для стилистических обычно хватает prettier.io, а логические придется вручную собирать среди кучи плагинов, о которых я говорил выше.
В погоне за высоким покрытием, многие фронты упарываются по jestjs.io/docs/ru/snapsh… (не путать с тестированием скриншотами!)
Но я не понимаю что именно тестирует snapshot. Какая мне разница в какую структуру отрендерился React? Какие гарантии нам дает эта структура?
В теории звучит классно: кидаем в пропсы {isLoading: true} и в снапшоте мы увидим что срендерился какой-нибудь <Spin />. А если кто-то сломает наш компонент, то мы визуально (!) увидим, что снапшот поменялся и теперь там нет спиннера.
Секрет в том, что никто никогда не смотрит что там в снапшоте. Потому что они огромные и постоянно меняются.
Но если хотите продать бизнесу идею, что у вас покрытие тестами 146%, то можно использовать.
Нормальный тест в этом случае должен быть примерно таким: рендерим компонент с { isLoading: true }, а в теле компонента просто ищем <Spin /> с помощью enzymejs.github.io/enzyme/
Нашли - хорошо, нет - нет.