А кто-нибудь test.check использует?
Я не понимю в чем его полезность и какой класс ошибок он находит.

Толку от того, что я условный sort проверю на 100 массивах, а не на одном?

Или за счет него можно увеличить покрытие и "автоматически" покрывать разные ветки алгоритма?

Два наиболее популярных подхода к разработке под React Native:
- Expo SDK (проще, но много ограничений, типа неподдержки Bluetooth, список есть в доках)
- Ejected Expo / чистый React Native (больнее, но практически без ограничений)

Во втором случае возможности примерно ничем неограничены (в частности, делали у себя геолокацию в бэкграунде), даже если чего-то не хватает всегда можно написать свой нативный модуль и подключить из JS (так тоже делали для кастомной интеграции с Raspberry Pi). Главная проблема с React Native у нас была в поддержке нативных зависимостей (gradle / cocoapods), но кажется с этим проблемы будут и при нативной разработке. Еще с перфомансом могут быть проблемы, но там уже зависит от конкретной задачи.

Из очевидных преимуществ: можно использовать любимые re-frame / fulcro и подключаться к процессу через REPL. Насколько знаю, в shadow-cljs сейчас хорошая поддержка React Native, Томас Хеллер специально выделил на него много времени летом.

привет, ты в курсе как настроить RN проект?

или в случае с функцией рендеринга, мне нужно проверять,
что сколько сообщений предали, столько и отрендерили?
т.е. тест упадет, если кто-то будет фильтровать или добавлять сообщения в тестируемой функции.
а в чем польза?