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

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

P> — композицию функциями, это основное, ради чего его стоит смотреть.
Я не знаю на какой вопрос ты отвечал. Напомню вопрос: "моки есть?". Варианты ответа: "Да", "Нет".

P>>>И точно так же похрен на ваши классы и интерфейсы. Но вы их не стесняетесь использовать, а структурная эквивалентность это ужос-ужос.
P>·>Так я это и говорю, похрен на эквивалентность, и на классы, интерфейсы тоже похрен. Важно чтобы код выражал ожидания пользователя, а не что =="select *". Пользователь может ожидать, что "для такого фильтра вернуть такой-то список штуковин". А у тебя "для такого фильтра верунть такой sql-код и использовать такие-то приватные методы".
P>Похоже, объяснения Синклера и мои про data complexity вам не помогли. Нету у вас варианта покрыть фильтры тестами на данных. Ради каждого теста, условно, вам надо не 2-3 элемента забрасывать в БД, а кучу данных во все таблицы которые учавствуют прямо или косвенно.
P>Отсюда ясно, что мелкие тесты фильтров вы будете гонять на бд близкой к боевой. Ну или игнорировать такую проблему делая вид что "и так сойдет"
Совершенно верно, именно эта альтернатива и имеет место быть. Я использую подход "гонять на бд близкой к боевой" (только не по количеству записей, а по качеству), а у вас подход "и так сойдет" + куча хрупких бесполезных тестов.

P>>>А ифы, циклы, классы, экземпляры зачем вашим пользователям? А что если понадобится поменять один класс-интерфейс на другой?
P>·>Ровно та же проблема, если понадобится поменять твою структуру на другую.
P>Вы снова игнорируете аргументы — глубина и частота правок зависят от количества зависимостей, которое у вас получается конским. У меня же простой маппер. Его править придется только в том случае, если поменяется БЛ. У вас — любое изменение дизайна, например, ради оптимизации.
Количество зависимостей зависит от сложности задачи, моки тут не при чём. Если у тебя простой маппер, то и у меня будет простой репо.

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

P>>Я вам сказал, что при переходе от одного дизайна к другому моки отваливаются. Если вы мокнули репозиторий в одном варианте, а в другом варианте репозиторий вызывается не там, не так, не тогда — всё, приплыли.
P>Голословно заявил, да.

Я согласился с тем, что ты это заявил, а не то, что я с этим заявлением согласился.

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

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

P>Это две разные задачи. Вторую можно игнорировать, переложить на интеграционные, если у вас один единственный вариант запроса. А если у вас сложное вычисление — то интеграционными вы вспотеете всё это тестировать. И моки вам точно так же не помогут.
Помогут совместно с конформационными тестами.

P>>>SQL потому, что фильтры сделаны именно так.
P>·>Именно — и это отстой. Тестируете детали как сделано, что works as coded.
P>Тестируется вычисление фильтров, которое довольно сложное.
Без тестирования того факта, что вычисленный фильтр, тот самый твой "pattern" — правильный — это бесполезно.

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