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

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

>>Мой поинт в том, что моки это не про то как пишется код, функциями, классами или чёртом лысым, а про внешние зависимости. И никакой правильный дизайн от них не избавляет, т.к. зависимости диктуются требованиями, а не дизайном. Если у тебя есть субд, будут моки, как ни дизайни. Ну или если у тебя хоумпейдж, а там что угодно делай, не важно.
P>Зависимости — требованиями, а способ их протаскивания — дизайном. Соответственно, моки это обрезание тех зависимостей, которые вы же сами затолкали куда поглубже, да еще неглядя.
Пофиг. Зависимости надо мокать. Точка. В этом твоём потоке речи единственный факт: "моки это обрезание зависимостей". А остальное — бессмысленные фантазии.

P>>>Что раз Фаулер так делает, то иначе ну никак нельзя?
P>·>Нельзя. И ты ещё не показал, что можно.
P>Серьёзная логика. А еще Фаулер показал олдскульный жээс и вдвое большее количество кода, чем нужно, даже с его подходом.
Серьёзная, да. Ни показать своё решение, ни улучшить чужое ты не можешь.

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

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

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

P>>>Т.е., условно, вы выяснили, что не успеваете, опаньки! И надо выталкивать процессинг в очередь. Упс — написали тесты, покрыли моками, выбросили моки, переписали тесты, но уже на других моках, ой...
P>·>Это требует согласования с бизнесом, а не просто так, чтобы не было тех чудес как у тебя бывает.
P>Я так вижу, бизнес вам имена классов и названия методов диктует, да еще 100500 готовых тестов подкидывает.
Раньше после нажатия на кнопочку "создать" появлялась кнопочка "поменять" и она работала, но ты сделал очень такое "нефункциональное" изменение, и теперь эту кнопочку можно нажимать только через пять минут, а до этого какие-то невнятные ошибки. Молодец, чё, а юзерам всегда можно сказать "have you tried to turning it on and off again?". Зато тесты не сломались!

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

Автор: ·
Дата: 05.02.24

.

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

P>Если вы сами пишете фильтры — а именно такую задачу я вам предложил, то это ваша ответсвенность учесть все возможные кейсы того, как хранятся и кодируются данные в бд — имена колонок, таблиц, строк, подстрок, кусков json, итд итд.
P>Фактически, вы пишете ни больше, ни меньше, а небольшой компилятор из json в sql. Только у вас нет этих самых эталонов — под вашу бд и придумки их никто не заготовил.
Вот я и не понимаю каким образом ты собираешься проверять, что этот самый sql выдаёт хоть какие-то правильные данные, а не > кто-то перепутал с < на какой-то комбинации входных данных. И не один раз "проверить" (а на самом деле скопипастить из реализации в тест) в процессе набора кода, но и для регрессии.

P>·>Я не знаю что ты в этом месте понимаешь под "паттерн", но я всегда имел в виду твой конкретный "const pattern =" вот тут

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

. Такой паттерн вручную прповерять — большая беда, надо тестировать с бд автоматически.
P>Похоже, вы что Фаулера, что меня, понимаете както слишком буквально. Я вам показал перевод из рабочего в минимально понятный здесь, вне контекста.
Конечно, я ни телепатией, ни безграничной фантазией не обладаю. Что написано, то и читаю.

P>1. получили рабочий паттерн
P>2. строим маппер вокруг этого паттерна
Что за маппер вокруг паттерна? У тебя маппер был частью паттерна как transformations: out:[fn1]

P>п1 — паттерн тестируется на бд, далее — интеграционными тестами
Тут два варианта:
Этих паттернов будут на каждый сценарий/юнит-тест. Т.е. кол-во ручного тестирования и и-тестов получается такое же. Следовательно смысла от таких тестов ноль.
Этих паттерны не будут покрываться интеграцией, а значит опечатки в тексте sql скопипасченные из реализации в тест и регрессии будут обнаруживаться только на проде юзерами.

P>п2 — построение запроса тестируется как все мапперы, без исключения
P>Без п2 вы спокойно напоретесь на кейс с уязвимостью, или поломкой на энкодинге данных, или с (не)подтягиванием данных из (не)тех таблиц
У тебя что-то очень не то с дизайном, что у тебя какие-то технические детали с энкодингом данных намешаны с бизнес-логикой реализации сценариев.

P>>>- сервис или бд или сторадж требует эспейпить, энкодить, инлайнить, склеивать, подставлять итд и тд
P>·>Так это сервис требует, а не твоя бизнес-логика, это и будет конф-тест тестировать.
P>Подробнее — кто и где выдаст вам конф-тест, что запросы смогут внятн что работать с такими вещами — email в таблице users это сам емейл строкой, а email в таблице reply будет mailto:&lt;email&gt;, а в customer он будет в колонке типа json с названием поля 'details' который есть список имя-значение.
Я не понял что ты тут спрашиваешь. Какой ещё емейл?

P>>>Фильтр который вы пишете, это ровно такой же специализированый клиент. И тут, о чудо, можно обходиться без всех таких кейсов
P>·>Это будет код и тесты клиента для протокола, а не код бизнес-логики твеого приложения, которое этого клиента использует.
P>А разница то какая? Вы одну часть тестов назвали другим именем, от этого сложность поменялась?
Поменялась, т.к. отделили мух от котлет. И вместо умножения комбинаций, мы тестируем их сумму.
Т.е. правила енкодинга определяются для типов данных, например, в строках надо non-ascii енкодить. А бизнес-логика работает со значениниями. И все значения firstname/lastname/&c это строки, енкодинг которых уже покрыт. И не надо отдельно проверять что каждое поле правильно енкодится.

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

А как ты его проверишь-то?

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

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

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

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

P>Т.е. это те самые ошибки которые вы на тестах бд не увидите. Но они видны при построении запроса.
Как они видны-то? Где что красненьким подчеркнётся?

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