MK
О наболевшем. Концептуально.
Как вы относитесь к тестированию с моками (когда test doubles используются чтобы "заткнуть" зависимости)?
Мой опыт ограничен ютубом и принятыми практиками в компаниях в которых я работал. Мне кажется, что подход "давайте заткнем все зависимости моками и стабами" ошибочный. Те тесты с моками что мне попадаются на работе (angularjs, angular2+) выглядят ужасно - сотня строк кода в beforeEach которые сетапят моки и данные для тестов, и не понятно где код соответствует окружению на продакшине и данные соответствуют тем, что на проде, а где test doubles смысл которых заткнуть зависимость дабы тесты не упали с каким-нибудь window is not defined.
Может кто видел в дикой природе open source уместные тесты с оправданными test doubles?
Как вы относитесь к тестированию с моками (когда test doubles используются чтобы "заткнуть" зависимости)?
Мой опыт ограничен ютубом и принятыми практиками в компаниях в которых я работал. Мне кажется, что подход "давайте заткнем все зависимости моками и стабами" ошибочный. Те тесты с моками что мне попадаются на работе (angularjs, angular2+) выглядят ужасно - сотня строк кода в beforeEach которые сетапят моки и данные для тестов, и не понятно где код соответствует окружению на продакшине и данные соответствуют тем, что на проде, а где test doubles смысл которых заткнуть зависимость дабы тесты не упали с каким-нибудь window is not defined.
Может кто видел в дикой природе open source уместные тесты с оправданными test doubles?
если в двух словах - идея моков в том, что делая запрос на сервис, который уже покрыт тестами, нам не нужно тестировать сам сервис (так как это уже сделано)
