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

P>>Вы раз за разом повторяете что верите в моки. Зачем? Это ж не аргумент, зато выглядит смешно.
·>Без моков внешних зависимостей ты не можешь тестировать свой код если эта самая зависимость по разным причинам недоступна.

Слишком категорично. Правильно так — часть тестов прогнать не получится. Соответсвенно в моки можно выносить не вообще всё, а только такие кейсы, без которых ну никак нельзя.

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

Это и есть пересказ всего, что изложено в clean architecture. Я уже приводил пример, вы прицепились к проверке sql и до сих пор успокоиться не можете.
Какой смысл приводить еще один пример, если вы еще на предыдущий продолжаете наскакивать?


P>>Кто вам такое сказал? Вам нужно редактировать не все отношения юзера, а только user-facing. Все остальное вы вас не заботит.
·>Не распарсил.

Очень просто — редактироавние после записи нужно для конкретных целей, например — что бы администратор мог подправить свойства только что созданного юзера, а не ждать пять минут.
Соответсвенно, в самом запросе мы обеспечиваем ровно этот минимум, а вообще всё, включая паблик кей спейса юзера
Если ваш бизнес аналиитк затребовал вообще всё такое — то вы приплыли.

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

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

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

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

Непонятно. Это вы тестируете внешние зависимости что ли? Непонятно. Как это к задаче с фильтрами относится?

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

Совсем необязательно. Частный случай маппера проще написать, проще протестировать. обобщенный translateJsonToSql это забег на месяцы или даже годы. Соответсвенно, наш маппер будет просто выдавать запрос createUser, в том виде, как требуется под именно эту задачу
1. все маппинги, с учетом всех дикостей схемы и бд
2. параметры
3. выражение, приоритеты
4. и энкодинг, без этого никуда

В вашем случае вы 1, 2, 3 и 4 будете проверять косвенными тестами, которые заведомо дырявые.

P>>Я ж вам объяснил раз пять
P>>1. находим паттерн и проверяем его
·>Где находим? Как проверяем? Когда проверяем?

Извините, но вам стоит читать внимательнее. Я последее время слишком часто цитирую самого себя. Не можете удерживать контекст — чего вам неймется, "в интернете ктото неправ"?

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

Все код был даден, отмотайте и посмотрите, это всё та же структурная эквивалентность запроса к бд.

P>>Это нужно на тот случай, если некто решит сделать "быстрый маленький фикс" после того, как вы уволитесь и контролировать код перестанете
·>Да ты меня запутал. Была и трансляция, и трансформация, и маппер, и паттерн, и ещё чего. Я уже перестал понимать кто на ком стоял.

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

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

Я вам продолжаю приводить тот же самый пример — фильтры, когда из за ошибки в построении запроса вгружается вся бд. Вы его усиленно игнорируете.

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

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

·>В моей схеме будут тесты репо+бд, которые тестируют только часть системы, относящуюся к персистенсу.

И как вы протестируете, что у вас невозможна ситуация, что прод вгружает вообще всё?

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

Я ж вам говорил — некорректный запрос в тестах может выдавать корректный результат. И примеры привел.

·>Ты так и не рассказал как _тестировать_ валидность запроса. Сравнение с твоим pattern ничего о валидности не говорит.

Валидность вообще всех запросов проверить не выйдет — та самая data complexity. Зато можно проверить известные проблемы для тех случаев, когда точная комбинация входа неизвестна.

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

Это значит, что вам нужно каждый такой кейс или через базу гонять, или же написать маппер, который можно дополнительно покрыть тестами, где учтем все возможные кейсы что есть в бд прода, или нам известно, что такие будут.

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

Вы до сих пор не показали решения. Комбинация параметров вам неизвестна. Действуйте.

P>>Даже если в интеграционных тестах у меня не будет 100_000_000_000 записей, ничего страшного — запрос всё равно будет с безопасной структурой.
·>Как ты отличишь в тесте запрос с безопасной структурой от запроса с небезопасной?

В зависимости от задачи. Например — двойная фильтрация. Часть фильтров в самом запросе, ограничивают выборку, не параметризуются, часть — параметры для фильтрации оставшегося.
Теперь что бы вы не подкидывали в фильтр, у вас никогда не будет кейса "вгрузить всё"

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

Тест — показал, только вы его понять не можете.

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

Это именно ваш подход — записать три значения в бд и надеяться что этого хватит. А как протестировать "запрос не тащит откуда не надо" вы не показали.

P>>Читаем вместе:
P>>

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

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

Вы дурака валяете? deep.eq.pattern это тест для п2. Тесты для п1 — обычные интеграционные.

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

По числу юз кейсов. Все юз кейсы должны быть покрыты интеграционными тестами.

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

Покрыть все возможные комбинации фильтров тестом с бд — нереально. Вы можете покрыть ну 5, ну 10, ну 50, но если у вас фильтров на страницу — вы ошалеете. Здесь забег на тысячи комбинаций.
На каждую комбинацию накидать минимальную бд — уже мало реально.
Особенно что нужно проверять и кейсы "не тащим откуда не надо"
Т.е. каждая комбинация это тесты вида "тащим откуда надо" + тесты вида "не тащим откуда не надо" коих много больше.