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

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

P>Есть у фаулера моки или нет — в данном примере он демонстрирует совсем другое!
Это твои личные заморочки что конкретно _ты_ увидел в этой демонстрации. Суть в том, что даже в таком тривиальном примере мок есть и это факт, а факт вещь упрямая. Если ты считаешь, что можно по-другому — весь код у тебя есть, форкни, сделай всё как считаешь должным.

P>·>Совершенно верно, именно эта альтернатива и имеет место быть. Я испоо льзую подход "гонять на бд близкой к боевой" (только не по количеству записей, а по качеству), а у вас подход "и так сойдет" + куча хрупких бесполезных тестов.
P>То есть, вы снова предлагаете бороться с data complexity посредством большого количества тестов на реальной бд.
Нет, такое я не предгалаю.

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

P>·>Количество зависимостей зависит от сложности задачи, моки тут не при чём. Если у тебя простой маппер, то и у меня будет простой репо.
P>Маппер тестируется простыми юнит-тестами. А ваш репозиторий, с ваших слов, надо "гонять на бд близкой к боевой"
P>И теперь остаётся надеяться на квалификацию того, кто бдет запорлнять эту бд — человечески фактор.
Я на это уже отвечал.

P>·>Я согласился с тем, что ты это заявил, а не то, что я с этим заявлением согласился
P>Итого — вы тестируете контролер, который вызывает репозиторий. Мок нужен? Нужен.
Он нужен не потому, что я тестирую контроллер, а потому что я отрезаю медленный и неуклюжий, но простой переситсенс от быстрой, но сложной бизнес-логики.

P>Второй вариант, после оптимизации, вам приходится сначала писать в очередь, а сам репозиторий будет вызван другим процессом/сервисом при чтении из очереди.
P>Функциональных изменений нет.
Есть, конечно. Например, изменяется транзакционность, согласованность, &c. Ты это даже не понимаешь, что это именно функциональность. Отсюда у тебя потом ВНЕЗАПНО возникают чудесные вещи типа "после того, как сделал var u = service.CreateUser(...), нужно выждать не менее 5 минут перед service.UpdateUser(u, ...)".

P>when(repo.get(v1)).thenReturn(r1); when(repo.get(v2)).thenReturn(r2);.

get-return это запрос-ответ. Неясно как это можно переписать на очередь без значительного изменения функциональности.

P>>>1 Задача "работает ли сервис с тем и этим" решается интеграционными тестами.
P>·>В тривиальных случаях только. В реальных случаях нужны конформационные тесты.
P>Это разновидность интеграционных. Вы снова играете в слова.
Да у тебя всё разновидность интеграционных. Конформационные тесты подразумевают, что внешний сервис тестируется отдельно от проекта. И проект отдельно тестируется с моками внешнего сервиса. Что с чем тут интегриуется — я не могу представить, моя фантазия не настолько безграничная.

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

P> А вызов другого сервиса будете тестировать на боевом сервисе?
Нет. Я же написал как. Несколько раз.

P>У вас здесь ровно та же data complexity.
P>Например, мы можем проверить, что делаем правильный энкодинг, правильную склейку, правильный маппинг, правильный эскейпинг, итд и тд.
Не можете. Такими тестами вы можете проверить, что текст запроса равен select *...., но не можете проверить, что он правильный. Правильность текста запроса будут проверять только ваши юзеры в проде, т.к. и интеграционными тестами не можете покрыть каждый запрос, ибо data complexity для тестов проекта в сборе выше, чем в тестах реп.

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

P>·>Без тестирования того факта, что вычисленный фильтр, тот самый твой "pattern" — правильный — это бесполезно.
P>С этим никто и не спорит!!! Вы хоть читаете?
P>1) Рабочий паттерн или нет — это проверяется на бд, в идеале, той, что содержит реальные данные. А они могут появиться только после релиза в следующем году?
P>Вы что, пойдете к менеджеру и скажете "нет боевой базы" я запрос через год напишу?
Т.е. ты не можешь написать тест т.к. для проверки паттерна у тебя ещё нет реальных данных? Совершенно верно. И это плохо. Не надо так делать.

P>2) При этом для реализации фильтра вам нужно понимать, что возможные параметры будут давать рабочие паттерны.
P>Тестов только для 1) недостаточно, т.к. например ваш маппер рендерит 'test1 test2' вместо 'test1','test2'. Такое вы проверите только на тех наборах данных, где есть пробел.
P>А если вдруг нужно энкодить всё многообразие спецсимволов, юникод строк
P>А потом может оказаться так, что некоторые параметры надо энкодить так, другие — эдак, один и тот же параметр в зависимости от места применения должен кодироваться то так, то эдак.
P>И всё это вы собираетесь "гонять на бд близкой к боевой"
И? Предлагаешь это не тестировать вообще? По факту ты просто загоняешь свои assumptions что надо "так, а не эдак" в свой pattern и оставляешь это вообще не покрытым вообще никак. Поэтому и необходимы конф-тесты вида, что repo.save(...."многообразие спецсимволов"); assertThat(repo.load(....)).isGood() на системе близкой к боевой, а не просто так как тебе кажется должно быть. Имея такие тесты можно уже спокойно тестировать свою бизнес-логику моками вида verify(repo).save(...."simple value") зная, что энкодинг спецсиволов уже проверен конф-тестами.

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