Здравствуйте, ·, Вы писали:
P>>Есть у фаулера моки или нет — в данном примере он демонстрирует совсем другое!
·>Это твои личные заморочки что конкретно _ты_ увидел в этой демонстрации.
Даем слово Фаулеру, again
By choosing to fulfill dependency contracts with functions rather than classes, minimizing the code sharing between modules and driving the design through tests, I can create a system composed of highly discrete, evolvable, but still type-safe modules
Фаулер пишет, что он взял функции вместо классов. Это и есть его цель. А вы думаете, что он показывал, будто без моков нельзя
> Суть в том, что даже в таком тривиальном примере мок есть и это факт, а факт вещь упрямая.
Что раз Фаулер так делает, то иначе ну никак нельзя? Моки можно всунуть куда угодно, хоть для теста синусов и косинусов, — это ничего не говорит.
P>>·>Совершенно верно, именно эта альтернатива и имеет место быть. Я испоо льзую подход "гонять на бд близкой к боевой" (только не по количеству записей, а по качеству), а у вас подход "и так сойдет" + куча хрупких бесполезных тестов.
P>>То есть, вы снова предлагаете бороться с data complexity посредством большого количества тестов на реальной бд.
·>Нет, такое я не предгалаю.
Именно это вы и говорите. Ну, как вариант, не читаете.
Речь именно про фильтры. Смотрите сами:
Отсюда ясно, что мелкие тесты фильтров вы будете гонять на бд близкоагй к боевой. Ну или игнорировать такую проблему делая вид что "и так сойдет"
·>Совершенно верно, именно эта альтернатива и имеет место быть. Я испоо льзую подход "гонять на бд близкой к боевой"
И вы предлагаете вместо этих тестов гонять всё через бд. Откуда ясно, что 1 время прогона увеличивается на порядки, 2 боевых данных у вас нет — пойдете к менедеджеру "Вася, я тесты в следуюем году подкину"
P>>Итого — вы тестируете контролер, который вызывает репозиторий. Мок нужен? Нужен.
·>Он нужен не потому, что я тестирую контроллер, а потому что я отрезаю медленный и неуклюжий, но простой переситсенс от быстрой, но сложной бизнес-логики.
Сейчас важно, что он нужен.
P>>Второй вариант, после оптимизации, вам приходится сначала писать в очередь, а сам репозиторий будет вызван другим процессом/сервисом при чтении из очереди.
P>>Функциональных изменений нет.
·>Есть, конечно. Например, изменяется транзакционность, согласованность, &c. Ты это даже не понимаешь, что это именно функциональность.
Согласованность, транзакционность, задержка — это всё НЕФУНКЦИОНАЛЬНЫЕ.
Т.е., условно, вы выяснили, что не успеваете, опаньки! И надо выталкивать процессинг в очередь. Упс — написали тесты, покрыли моками, выбросили моки, переписали тесты, но уже на других моках, ой...
·>P>>when(repo.get(v1)).thenReturn(r1); when(repo.get(v2)).thenReturn(r2);.
·>
·>get-return это запрос-ответ. Неясно как это можно переписать на очередь без значительного изменения функциональности.
Вам сюда:
https://en.wikipedia.org/wiki/Non-functional_requirement
P>>Это разновидность интеграционных. Вы снова играете в слова.
·>Да у тебя всё разновидность интеграционных. Конформационные тесты подразумевают, что внешний сервис тестируется отдельно от проекта. И проект отдельно тестируется с моками внешнего сервиса. Что с чем тут интегриуется — я не могу представить, моя фантазия не настолько безграничная.
Интеграция начинается с момента, когда одна ваша функция вызывает другую вашу функцию. Конформационный тест требует запуска приложения или подсистемы, что автоматически означает интеграционный уровень.
Правильно понимаю, вы собираетесь тестировать эскейпинг каких кавычек, собирая приложение и запуская его против мока внешнего сервиса?
Весело у вас там.
P>>Вы ухитряетесь противоречить себе же в одном абзаце. Репозиторий вы гоняете на боевой бд.
·>Это ты опять врёшь, надеюсь, что хоть чуточку краснея.
Вот ваши слова про репозиторий "гонять на бд близкой к боевой"
Так и вижу — тесты на эскейпинг символов прогонять на клоне прода. Собственно, это и есть ваша идея применения конформационных тестов.
P>>Например, мы можем проверить, что делаем правильный энкодинг, правильную склейку, правильный маппинг, правильный эскейпинг, итд и тд.
·>Не можете. Такими тестами вы можете проверить, что текст запроса равен select *...., но не можете проверить, что он правильный. Правильность текста запроса будут проверять только ваши юзеры в проде, т.к. и интеграционными тестами не можете покрыть каждый запрос, ибо data complexity для тестов проекта в сборе выше, чем в тестах реп.
В который раз объясняю. Нам нужны 2 условия(ДВА!)
1. рабочий паттерн запроса — это проверяется сначала руками, а потом тестом против бд минимально заполненой под задачу
2. рабочая схема построения такого паттерна
1 — необходимое условие
1 + 2 необходимое и достаточное
Почему недостаточно п1
— сервис или бд или сторадж требует эспейпить, энкодить, инлайнить, склеивать, подставлять итд и тд
— маппер параметр->значение это целая куча кейсов, много больше, чем вы можете себе позволить методом "гонять на бд близкой к боевой"
P>>Подробнее — как вам моки помогут гарантировать, что всё многообразие символов вы энкодите согласно протоколу?
·>"согласно протоколу" — это и есть конформационные тесты, по определению. Моки же позволяют не маяться дурью гарантирования энкодинга в тестах вашей бизнес-логики.
Вы реализацию хоть какого клиентского протокола видели когда нибудь? Там сотни и тысячи тестов покрывают кейсы вида '$var- заменяем на значение var с удалением всех пробельных символов после нее'
Фильтр который вы пишете, это ровно такой же специализированый клиент. И тут, о чудо, можно обходиться без всех таких кейсов
P>>Вы что, пойдете к менеджеру и скажете "нет боевой базы" я запрос через год напишу?
·>Т.е. ты не можешь написать тест т.к. для проверки паттерна у тебя ещё нет реальных данных? Совершенно верно. И это плохо. Не надо так делать.
Где взять боевые данные за февраль 2025го? Вы в курсе, что сейчас 2024й год ?
P>>А потом может оказаться так, что некоторые параметры надо энкодить так, другие — эдак, один и тот же параметр в зависимости от места применения должен кодироваться то так, то эдак.
P>>И всё это вы собираетесь "гонять на бд близкой к боевой"
·>И? Предлагаешь это не тестировать вообще?
Я уже третий месяц рассказываю как именно это нужно тестировать.
>По факту ты просто загоняешь свои assumptions что надо "так, а не эдак" в свой pattern и оставляешь это вообще не покрытым вообще никак.
Работает ли паттерн корретно, и строится ли он корректно — это два множества вариантов которые всего лишь пересекаются.
> зная, что энкодинг спецсиволов уже проверен конф-тестами.
Я так и думал — вы будете собирать пол-приложения что бы погонять против внешнего сервиса на предмет "заэскейпили кавычку"
P>>В том, что в фильтр приходит конское количество данных самых разных типов, а на выходе должны быть только рабочие паттерны
·>Ты всё ещё скрываешь как же ты ассертишь рабочесть паттернов. Кода я, конечно, не увижу, т.к. это делаешь на честном слове, вручную, если не забыл.
Я ж вам сказал — рабочий паттерн или нет, это проверяем до того, как начнем код коммитить, руками на бд. Интеграционные тесты проверяют его еще раз, на бд.
А дальше нужно покрыть тестами всю мелочевку — построение запроса таким образом, что бы получался рабочий паттерн
