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

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

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

P>·>Раньше после нажатия на кнопочку "создать" появлялась кнопочка "поменять" и она работала, но ты сделал очень такое "нефункциональное" изменение, и теперь эту кнопочку можно нажимать только через пять минут, а до этого какие-то невнятные ошибки. Молодец, чё, а юзерам всегда можно сказать "have you tried to turning it on and off again?". Зато тесты не сломались!
P>Кто вам такое сказал? Вам нужно редактировать не все отношения юзера, а только user-facing. Все остальное вы вас не заботит.
Не распарсил.

P>То есть, здесь вы назвали интеграционные тесты conformance.
Наверное я плохо выразился, я не назвал, я возразил, что такие вещи надо не интеграционными тестами тестировать а конформационными, иначе будет беда с процессом релиза когда внешние система(ы) недоступны. Цитирую: "мы можем пройти acceptance для нашего проекта только в момент когда _все_ внешние тестовые системы работают".

У Sinclair был тривиальнейший случай "когда мы работали с CREST API от Microsoft". Т.е. внешняя зависимость одна и от более-менее надёжного вендора, у которого обычно всё работает. В более-менее больших сложных проектах такой халявы не бывает.

P>Если вы все еще не согласны — объясните внятно
P>1 кто пишет эти conformance tests
Мы.

P>2 какой код должен выполниться, что бы пройти эти тесты
Код этих тестов. Поднимать само приложение для этого не нужно. Никакой интеграции. Цитирую: "Conformance tests можно гонять независимо от наших релизов".

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

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

P>1. благодаря правильному паттерну у нас рабочая схема
P>2. благодаря 2 у нас правильные подстановки в этот паттерн
Я не понял детали. Код покажи.

P>·>Что за маппер вокруг паттерна? У тебя маппер был частью паттерна как transformations: out:[fn1]
P>А название таблицы само выросло, да? Подстановка параметров, условий, названий колонок, таблиц, подстановка fn1 и fn2 тоже само? Это именно работа маппера — по json получить рабочий запрос, который будет соответствовать нашим ожиданиям
P>Это нужно на тот случай, если некто решит сделать "быстрый маленький фикс" после того, как вы уволитесь и контролировать код перестанете
Да ты меня запутал. Была и трансляция, и трансформация, и маппер, и паттерн, и ещё чего. Я уже перестал понимать кто на ком стоял.

P>·>Этих паттернов будут на каждый сценарий/юнит-тест. Т.е. кол-во ручного тестирования и и-тестов получается такое же. Следовательно смысла от таких тестов ноль.
P>В вашей схеме ровно так же. Только вы построение запроса никак не контролируете.
Не правда, что ровно так же. Ручное тестирование исключается, т.к. есть тесты репо+бд. А построение не контролирую, потому что считаю что запрос не важно как строится, т.к. это детали реализации, важно что запрос работает в соответствии с бизнес-ожиданиями. Конкретный пример когда это не сработает я так и не увидел.

P>·>Этих паттерны не будут покрываться интеграцией, а значит опечатки в тексте sql скопипасченные из реализации в тест и регрессии будут обнаруживаться только на проде юзерами.
P>Вы в адеквате? Я ж сказал — интеграционные тесты никуда не деваются. А вы читаете чтото своё.
Не деваются, но такие тесты которые ты имеешь в виду (проверяющие интеграцию в контроллере всего со всем) не могут покрыть все возможные комбинации.
В моей схеме будут тесты репо+бд, которые тестируют только часть системы, относящуюся к персистенсу.

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

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

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

P>·>А как ты его проверишь-то?
P>Примерно так же, как и вы. Только проверка паттерна мало что гарантирует. См выше про загрузку всей бд в память. Паттерн корректный, ошибочка при рендеринге некоторых комбинаций фильтров.
Я до сих пор не понимаю почему у тебя есть проблема с загрузкой всей бд в память, решается же элементарно.

P>>>а не конечный запрос, как у вас. Потому мне в будущее заглядывать не надо, цитирую себя "тестом бд минимально заполненой под задачу"
P>·>Ты уже запамятовал? Ты показывал код, где у тебя в паттерне был конечный запрос.
P>Это выхлоп билдера запросов. не рукописный sql, а результат билдера. Соответсвенно, мы можем проверить работу сложного маппера json -> sql, при чем гораздо плотнее, чем вашими косвенными тестами.
P>Например, я могу просто заложиться на юнит-тест, и потребовать двойную фильтрацию — первая по периоду, вторая — по параметрам, или вставить limit x, итд итд
P>И у меня точно не будет кейса "вгружаем всю бд в память".
P>Даже если в интеграционных тестах у меня не будет 100_000_000_000 записей, ничего страшного — запрос всё равно будет с безопасной структурой.
Как ты отличишь в тесте запрос с безопасной структурой от запроса с небезопасной?

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

P>Ваш никак не учитывает data complexity. Мой — именно на этом и строится, см пример выше про 100_000_000_000 записей.
Бла-бла-бла.

P>Т.е. мне нужно
P>1. быть в курсе про возможную проблему с загрузкой конской таблицы из за ошибок в построении фильтров
P>2. найти решение
P>3. зафиксировать теми тестами, которые вам кажутся лишними
Если у тебя не получается это зафиксировать это нормальными тестами, то создай новый топик, поможем, не бином ньютона.

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

P> Вы показали другой совсем другой тест — загрузим 1, если только что записали 1.
Я такой тест не показывал.

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

P>п1 — паттерн тестируется на бд, далее — интеграционными тестами

Где? Как? Напомню, у тебя было: deep.eq(pattern). В каком тут месте "тестируется на бд"?

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

P>Это какая то особенность вашего восприятия
Я воспринимаю то что написано, а не фантазирую.

P>·>Как они видны-то? Где что красненьким подчеркнётся?
P>См выше, "никогда не будем загружать всю бд в память" — для этого кейса у вас ни одного теста, а у меня хоть какие то.
Ну потому что ты "1. был в курсе" и написал хоть какой-то тест. Т.е. они были не видны, как ты обещал, а у вас видимо на проде у вас что-то навернулось и ты это "увидел".