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

P>>·>Так "да" или "нет"?
·>Т.е. прямой вопрос ты опять игнорируешь и продолжаешь лить воду.

Зачем? Прямой ответ уже был даден. Раз вы продолжаете вопрошать, значит вам точно надо чтото другое. Играйте в свои игры без меня.

P>>Фаулер пишет, что он взял функции вместо классов. Это и есть его цель. А вы думаете, что он показывал, будто без моков нельзя
·>Ещё бы, ведь в js тупо нет классов.

Одно из двух — вы пользуетесь Internet Explorer или у вас апдейты Лялиха поломались еще в нулевых.

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

Зависимости — требованиями, а способ их протаскивания — дизайном. Соответственно, моки это обрезание тех зависимостей, которые вы же сами затолкали куда поглубже, да еще неглядя.

P>>Что раз Фаулер так делает, то иначе ну никак нельзя?
·>Нельзя. И ты ещё не показал, что можно.

Серьёзная логика. А еще Фаулер показал олдскульный жээс и вдвое большее количество кода, чем нужно, даже с его подходом.
Полагаю, вы щас начнете удваивать количество кода и возвращаться на 8ю джаву?

P>>Моки можно всунуть куда угодно, хоть для теста синусов и косинусов, — это ничего не говорит.
·>Ты говорил, что моки и это всё — это старьё из 00х. Как оказалось — и тут ты налажал, т.к. статья 2023 года имеет те же самые "устаревшие" моки.

Статья совсем про другое, о чем сам же Фаулер и пишет — про композицию функций. А вы там только моки видите.

P>>Именно это вы и говорите. Ну, как вариант, не читаете.
·>Ты нафантазировал "на реальной бд", а я писал "на бд близкой к боевой (только не по количеству записей, а по качеству)". Разницу не видишь, да?

Небольшая разница — Data complexity говорит о том, что вам не покрыть и ничтожной части вариантов вашими тестами.

P>>·>Есть, конечно. Например, изменяется транзакционность, согласованность, &c. Ты это даже не понимаешь, что это именно функциональность.
P>> Согласованность, транзакционность, задержка — это всё НЕФУНКЦИОНАЛЬНЫЕ.
·>Как это? Возможность поизменять пользователя после его создания — это функциональное требование.

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

P>>Т.е., условно, вы выяснили, что не успеваете, опаньки! И надо выталкивать процессинг в очередь. Упс — написали тесты, покрыли моками, выбросили моки, переписали тесты, но уже на других моках, ой...
·>Это требует согласования с бизнесом, а не просто так, чтобы не было тех чудес как у тебя бывает.

Я так вижу, бизнес вам имена классов и названия методов диктует, да еще 100500 готовых тестов подкидывает.

P>>Интеграция начинается с момента, когда одна ваша функция вызывает другую вашу функцию. Конформационный тест требует запуска приложения или подсистемы, что автоматически означает интеграционный уровень.
·>Нет, конформационный тест не требует запуска приложения или системы. Читай мою переписку с Sinclair.

Вы наверное подумали, но забыли написать. Поиск по треду никаких пояснений, как вы используете конформационные тесты, не дал.
Могу рассказать, как это делается при реализации клиента под протокол — у вас есть 100500 эталонов на все случаи жизни, которые должен проглотить ваш клиент.
Ровно так же поступают и с компилятором — запускают и прогоняют 100500 примеров кода по спецификации.

Если вы сами пишете фильтры — а именно такую задачу я вам предложил, то это ваша ответсвенность учесть все возможные кейсы того, как хранятся и кодируются данные в бд — имена колонок, таблиц, строк, подстрок, кусков json, итд итд.
Фактически, вы пишете ни больше, ни меньше, а небольшой компилятор из json в sql. Только у вас нет этих самых эталонов — под вашу бд и придумки их никто не заготовил.

P>>В который раз объясняю. Нам нужны 2 условия(ДВА!)
P>>1. рабочий паттерн запроса — это проверяется сначала руками, а потом тестом против бд минимально заполненой под задачу
P>>2. рабочая схема построения такого паттерна
P>>1 — необходимое условие
P>>1 + 2 необходимое и достаточное
·>Я не знаю что ты в этом месте понимаешь под "паттерн", но я всегда имел в виду твой конкретный "const pattern =" вот тут

Автор: Pauel
Дата: 28.12.23

. Такой паттерн вручную прповерять — большая беда, надо тестировать с бд автоматически.

Похоже, вы что Фаулера, что меня, понимаете както слишком буквально. Я вам показал перевод из рабочего в минимально понятный здесь, вне контекста.
1. получили рабочий паттерн
2. строим маппер вокруг этого паттерна
п1 — паттерн тестируется на бд, далее — интеграционными тестами
п2 — построение запроса тестируется как все мапперы, без исключения

Без п2 вы спокойно напоретесь на кейс с уязвимостью, или поломкой на энкодинге данных, или с (не)подтягиванием данных из (не)тех таблиц

P>>- сервис или бд или сторадж требует эспейпить, энкодить, инлайнить, склеивать, подставлять итд и тд
·>Так это сервис требует, а не твоя бизнес-логика, это и будет конф-тест тестировать.

Подробнее — кто и где выдаст вам конф-тест, что запросы смогут внятн что работать с такими вещами — email в таблице users это сам емейл строкой, а email в таблице reply будет mailto:<email>, а в customer он будет в колонке типа json с названием поля 'details' который есть список имя-значение.

P>>Фильтр который вы пишете, это ровно такой же специализированый клиент. И тут, о чудо, можно обходиться без всех таких кейсов
·>Это будет код и тесты клиента для протокола, а не код бизнес-логики твеого приложения, которое этого клиента использует.

А разница то какая? Вы одну часть тестов назвали другим именем, от этого сложность поменялась?

P>>Где взять боевые данные за февраль 2025го? Вы в курсе, что сейчас 2024й год ?
·>Не знаю, ты рассказывай, ведь тебе требуется "Рабочий паттерн или нет — это проверяется на бд, в идеале, той, что содержит реальные данные". Рассказывай где-ты берёшь реальные данные за 2025 год для проверки работосбособности твоих паттернов.

Мне нужно всего лишь паттерн проверить, а не конечный запрос, как у вас. Потому мне в будущее заглядывать не надо, цитирую себя "тестом бд минимально заполненой под задачу"

P>>Я уже третий месяц рассказываю как именно это нужно тестировать.
·>Меня ответы "никак", "руками", "используя реальные данные за 2025 год" не устраивают. А с другими ответами ты не соглашаешься.

Смотрите внимательно — объяснение ниже я вам приводил уже около десятка раз

В который раз объясняю. Нам нужны 2 условия(ДВА!)
1. рабочий паттерн запроса — это проверяется сначала руками, а потом тестом против бд минимально заполненой под задачу
2. рабочая схема построения такого паттерна
1 — необходимое условие
1 + 2 необходимое и достаточное

P>>Работает ли паттерн корретно, и строится ли он корректно — это два множества вариантов которые всего лишь пересекаются.
·>Почему пересекаются? Каким образом некорректно построенный паттерн может работать корректно? Раз работает, значит построен.

Вот-вот. Вы здесь снова пишете, что не в курсе data complexity и объяснения Sinclair прошли мимо, и понимать это не хотите

·>Разница значительна: "Работает ли" — важно и нужно тестировать, инвариант диктуемый бизнесом, "строится ли" — это мелкие детали имплементации, которые меняются постоянно.

Вы что, не помните как в школе на математике или физике подгоняли решение под ответ? Правильный паттерн, некорректно построен, ответ верный — "Молодец, садись, два балла!".

Почему некорретно построеный паттерн дает корректный результат:
1. у вас нет данных на год вперёд, и половина базы вообще пустая.
2. у вас в бд только 1% частных случаев
3. вы думаете, что бд у вас заполнена верно, но реально это не так.
4. у вас в базе много данных, которые похожи друг на друга

Т.е. это те самые ошибки которые вы на тестах бд не увидите. Но они видны при построении запроса.

P>>А дальше нужно покрыть тестами всю мелочевку — построение запроса таким образом, что бы получался рабочий паттерн
·>Отстой.

Ну да, Фаулер пока не написал такую статью. Ждите еще 20 лет