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

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

Вы продолжаете играть в какие то игры, и задаёте много раз вопрос на который ответ даден несколько раз.
Есть у фаулера моки или нет — в данном примере он демонстрирует совсем другое!

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

То есть, вы снова предлагаете бороться с data complexity посредством большого количества тестов на реальной бд.
Вы раз за разом повторяете свое предложение, но почему то возмущаетесь, когда я вам про это напоминаю.

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

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

P>>

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

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

Итого — вы тестируете контролер, который вызывает репозиторий. Мок нужен? Нужен.
Второй вариант, после оптимизации, вам приходится сначала писать в очередь, а сам репозиторий будет вызван другим процессом/сервисом при чтении из очереди.
Функциональных изменений нет.
Теперь заглядываем в ваши тесты контроллера, и видим:

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

Самое забавное, вы продолжаете с этим несоглашаться

P>>1 Задача "работает ли сервис с тем и этим" решается интеграционными тестами.
·>В тривиальных случаях только. В реальных случаях нужны конформационные тесты.

Это разновидность интеграционных. Вы снова играете в слова.

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

Вы ухитряетесь противоречить себе же в одном абзаце. Репозиторий вы гоняете на боевой бд. А вызов другого сервиса будете тестировать на боевом сервисе?
У вас здесь ровно та же data complexity.
Например, мы можем проверить, что делаем правильный энкодинг, правильную склейку, правильный маппинг, правильный эскейпинг, итд и тд.

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

Подробнее — как вам моки помогут гарантировать, что всё многообразие символов вы энкодите согласно протоколу?

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

С этим никто и не спорит!!! Вы хоть читаете?
1) Рабочий паттерн или нет — это проверяется на бд, в идеале, той, что содержит реальные данные. А они могут появиться только после релиза в следующем году?
Вы что, пойдете к менеджеру и скажете "нет боевой базы" я запрос через год напишу?
2) При этом для реализации фильтра вам нужно понимать, что возможные параметры будут давать рабочие паттерны.

Тестов только для 1) недостаточно, т.к. например ваш маппер рендерит 'test1 test2' вместо 'test1','test2'. Такое вы проверите только на тех наборах данных, где есть пробел.
А если вдруг нужно энкодить всё многообразие спецсимволов, юникод строк
А потом может оказаться так, что некоторые параметры надо энкодить так, другие — эдак, один и тот же параметр в зависимости от места применения должен кодироваться то так, то эдак.
И всё это вы собираетесь "гонять на бд близкой к боевой"

P>>Вы так и не дали никакого адекватного решения для фильтров. Те примеры, что вы приводили именно для тестирования фильтров не годятся.
·>Я не понял в чём негодность.

В том, что в фильтр приходит конское количество данных самых разных типов, а на выходе должны быть только рабочие паттерны