Размышляю по поводу того, как писать близкие к идеалу юнит тесты (и фичи, которые поддаются такому тестированию), и пока выделил такие пункты
- моки это зло, по возможности нужно избегать их
- сайд эффекты выносить как можно дальше от основной логики (в дополнение к первому)
- тесты не должны даже поверхностно повторять функционал
- использовать подходы, такие как в jsverify
- изменение функционала не должно провоцировать равносильный фиксинг тестов

С учетом того, что в сети я нахожу много профанских статей о том, как писать юнит тесты, и на практике часто вижу тесты, которые пишутся "для галочки"

Что еще можете добавить?

Добро пожаловать в мир фаулера

Моки не зло

Все придумано до нас

Пока я не согласен практически со всеми пунктами

то есть малейшее изменение функционала, которое провоцирует фиксинг тестов - это норм?

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

Что значит "равносильное". Что значит изменение функциональности?
Если мы изменили публичное апи - надо править тесты

Значит вы их обрабатывает как часть апи. А являются ли они таковым?

Property based testing практически не применимо во фронтенде

допустим, есть функция, которая имеет внутри N вызовов с сайд эффектами, мы написали на нее тесты указав моки/стабы, и в какой-то момент после ее рефакторинга оказывается, что приложение крашится в том месте, где есть сайд эффект, хотя тесты как и прежде проходят. А вся причина в том, что mock не дал проверить ту часть

А не путаете ли вы e2e и unit-тесты?

нет

в целом, как по мне, UI более рационально тестировать через E2E, но увы...

Ну по хорошему тебе нужны интеграционные и юнит тесты. Юнит тесты позволят тебе сократить объём и дублирование интеграционных тестов

@xanf_ua может посоветуешь хорошую (на твой взгляд) книгу или статью со сборникам советов по написанию Unit-тестов?

Потому что я тоже нередко слышу от ребят что по максимуму необходимо избавляться от моков в unit-тестах

От каких ребят? Как они респ апи тестируют?

Трансляция задерживается(((