Comments 5
Я, преимущественно, воюю с облыжными заявлениями типа такого: «Стабы и моки нарушают инкапсуляцию». Не нарушают, если разработчик им не велит.
Там вопрос терминологии. Насколько я помню, xUnitPatterns предлагали называть стабами иммитаторы данных на неявных входах (indirect inputs), а моками - проверки на неявных выходах (indirect outputs). А это в свою очередь требует определённых знаний о реализации тестируемой системы (SUT), что в определённом смысле дает право говорить о нарушении инкапсуляции.
Какую часть этих знаний относить к контрактам, а какую к деталям реализации это частная проблема декомпозиции и выбранного уровня абстракции. Так или иначе все происходит по воле разработчика. Но судить его потомки будут в зависимости от того, в каких границах станут меняться требования.
Всё так.
Но вот мы с вами тут в кулуарах это можем обсудить, навести аксиоматику, расставить терминологические акценты, уточнить формулировочки, отполировать референсы, так сказать. А что усваивает из всей этой митинговой риторики неокрепший мозг среднего разработчика? — «Четыре ноги хорошо, две ноги плохо!».
Вот я и попытался проговорить, что как ни называй — хоть моками, хоть даблами, хоть фейками (стаб — это всё-таки заглушка, и она вообще ничего проверять не может по определению) — если всё сделать правильно, то пользы будет много, а вреда — не будет вовсе.
Чтобы отличить больного человека, можно рядом создать функционально такого же, но только здорового - а потом сравнить оригинал с фейком. Но можно купить градусник за три копейки и померить температуру.
Создать адекватный иммитатор для сложной системы может быть само по себе сложной задачей (как boto3 / moto для питона). Стратегически это вероятно будет хорошим решением. Но в частных случаях может быть целесообразнее обойтись более простыми средствами.
Я никогда нигде не предлагал все тесты вести через моки.
Но когда люди сталкиваются с проблемой тестирования в высококонкурентной среде — кроме моков, по сути, не существует механизма для создания повторяемых тестов.
Я тут не спорю, с интересом прочитал вашу статью, за что огромное спасибо. Разработка это инженерная дисциплина, а всё инженерные задачи решаются в конкретных ограничениях. Думаю каждый из нас сможет привести примеры из опыта, когда то или иное решение работало лучше, чем другое. Но в иной ситуации все может быть иначе. Именно поэтому существует все это многообразие различных подходов.
Еще пара слов о моках