Здравствуйте, Pauel, Вы писали:

P>·>При этом он меня обвинил в том, что мои тесты проверяют как написано, а не ожидания пользователей.
P>Я вам привожу общеизвестный факт — моки всех сортов обладают таким вот свойством. И вы показали почему то именно такие тесты, смотрите сами, что пишете.
Давай определимся. В том образцовом коде у Фаулера — моки есть?

>> А бревно в глазу не замечаете — пользователям-то похрен какая-то там эквивалентность у вас, структурная или не очень.
P>И точно так же похрен на ваши классы и интерфейсы. Но вы их не стесняетесь использовать, а структурная эквивалентность это ужос-ужос.
Так я это и говорю, похрен на эквивалентность, и на классы, интерфейсы тоже похрен. Важно чтобы код выражал ожидания пользователя, а не что =="select *". Пользователь может ожидать, что "для такого фильтра вернуть такой-то список штуковин". А у тебя "для такого фильтра верунть такой sql-код и использовать такие-то приватные методы".

P>·>И накой сдалась эта ваша AST вашим пользователям? А что если завтра понадобится заменить вашу AST на очередной TLA, то придётся переписывать все тесты, рискуя всё сломать.
P>А ифы, циклы, классы, экземпляры зачем вашим пользователям? А что если понадобится поменять один класс-интерфейс на другой?
Ровно та же проблема, если понадобится поменять твою структуру на другую.

P>Впрочем, вы уже сами согласились, что изменения дизайна сначала ломают моки.
Это ты опять что-то перефантазировал.

P>Я взял пример для иллюстрации подхода. В другом месте вместо sql будет json-like структура, которая отлично сравнивается и визуализируется — например, при запросах по http или orm.
P>Вот сегодня сделал тож самое для запросов к http rpc сервису — параметры, retry, api-key, итд. Теперь в тестах сразу видно, что именно уходит на сервис.
А толку? Ну уходит, а с чего ты решил, что сервис будет с этим ушедшим работать? Будешь тесты в проде гонять?

P>·>У тебя же now() лежит в коде бизнес-логики (как я понял из объяснений Pauel). Будет стоять в каждом втором методе контроллеров, т.е. в сотнях мест и код этот постоянно меняется.
P>У вас будет как минимум несколько этих composition root, т.к. юзкейсы разные. А следовательно будут ошибки вида "посмотрел не туда"
Эти же кусочки composition root будут использоваться и в тестах этих юзкейсов. От тестов моками отделяются "плохие" зависимости. Т.е. выделение "плохих" зависимостей — чисто техническое — медленное (сеть-диск-етс), неконтролируемое (системные штуки типа clock) и т.п. А юзкейсы — это логика, этот же код что в проде, что в тестах — один и тот же.

P>·>Ну как видишь эта самая фунция бизнес-логики состоит из меньших шагов бизнес логики с кучей "если-то". И это всё бизнес-логика. Вот и бей на части.
P>·>И где же тут эта ваша структурная эквивалентность? Где метапрограммирование? Где буквальный текст sql? И имя функции fn1?
P>Вы почему в моем примере видите только сравнение текста sql, и дальше этого смотреть не хотите.
Я вижу ровно то, что ты мне показал. Фантазии и телепатия — не моя стезя.

P>SQL потому, что фильтры сделаны именно так.
Именно — и это отстой. Тестируете детали как сделано, что works as coded.

P>Соответственно, можно подкинуть дешовых тестов используя структурную эквивалентность. Соответсвенно, фиксируем тестами свои ожидания, что бы будущие изменения в коде не сломали всё подряд
Это плохой критерий для выбора тестов.