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

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

P>>>Я вам уже много раз предлагал посмотреть clean architecture, глянуть, как там работают с бд. Вы хотите что бы я все это пересказал вам здесь?
P>·>Нет, я хочу чтобы ты код показал.
P>Это и есть пересказ всего, что изложено в clean architecture. Я уже приводил пример, вы прицепились к проверке sql и до сих пор успокоиться не можете.
P>Какой смысл приводить еще один пример, если вы еще на предыдущий продолжаете наскакивать?
Действительно. Какой смысл искать верное решение задачи, если в предыдущем были ошибки. Отличная логика!

P>>>Кто вам такое сказал? Вам нужно редактировать не все отношения юзера, а только user-facing. Все остальное вы вас не заботит.
P>·>Не распарсил.
P>Очень просто — редактироавние после записи нужно для конкретных целей, например — что бы администратор мог подправить свойства только что созданного юзера, а не ждать пять минут.
Это вроде очевидное требование. Необходимость пользователям ждать по пять минут перед тем как нажать кнопочку — должно быть серьёзно обоснованно и обговорено с заказчиком. Как ты это вообще представляешь? Кнопочка как обычно рисуется на экране, но пользователям надо в инструкции написать, что "не нажимайте кнопочку быстрее чем через 5 минут". Бред же. Если такое "нефункциональное" изменение вдруг понадобится, то оно потребует заметную переработку UI и т.п. Тесты просто обязаны грохнуться!

P>Соответсвенно, в самом запросе мы обеспечиваем ровно этот минимум, а вообще всё, включая паблик кей спейса юзера
P>Если ваш бизнес аналиитк затребовал вообще всё такое — то вы приплыли.
Я не в курсе что такое "паблик кей спейса юзера".

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

P>В вашем случае вы 1, 2, 3 и 4 будете проверять косвенными тестами, которые заведомо дырявые.
Не перекладывай с больной головы. Косвенные тесты как раз у вас, т.к. тестируют не поведение системы, а внутреннюю имплементацию; и с дырами в которые я тебе пальчиком тыкал несколько раз; да ещё и хрупкие.

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

P>·>Я не понял детали. Код покажи.
P>Все код был даден, отмотайте и посмотрите, это всё та же структурная эквивалентность запроса к бд.
Мы рассмотрели этот пример, ты вроде даже признал, что там лажа.

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

P>трансформация — часть маппера, трансформируем json в нужный нам вид, на выходе — делаем обратное преобразование.
Трансформация? Обратная? А что такое transformations? out:...? Это было частью pattern в твоём сниппете. Тут ты говоришь, что это часть маппера.
Ты можешь внятный код написать? Ты уже в своей терминологии сам запутался.

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

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

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

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

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

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

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

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

P>>>Даже если в интеграционных тестах у меня не будет 100_000_000_000 записей, ничего страшного — запрос всё равно будет с безопасной структурой.
P>·>Как ты отличишь в тесте запрос с безопасной структурой от запроса с небезопасной?
P>В зависимости от задачи. Например — двойная фильтрация. Часть фильтров в самом запросе, ограничивают выборку, не параметризуются, часть — параметры для фильтрации оставшегося.
P>Теперь что бы вы не подкидывали в фильтр, у вас никогда не будет кейса "вгрузить всё"
И что ты будешь ассертить в твоём тесте? sql.contains("LIMIT 1000")?

P>>>А вот вы так и не показали тест "никогда не будем загружать всю бд в память".
P>·>Ты тоже такой тест не показал.
P>Тест — показал, только вы его понять не можете.
Это который? "select * from users"?

P>>> Вы показали другой совсем другой тест — загрузим 1, если только что записали 1.
P>·>Я такой тест не показывал.
P>Это именно ваш подход — записать три значения в бд и надеяться что этого хватит. А как протестировать "запрос не тащит откуда не надо" вы не показали.
Показал. Запрос должен из условных трёх записей выбирать только условно две.

P>>>

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

P>·>Где? Как? Напомню, у тебя было: deep.eq(pattern). В каком тут месте "тестируется на бд"?
P>Вы дурака валяете? deep.eq.pattern это тест для п2. Тесты для п1 — обычные интеграционные.
Я читаю что написано. В цитате выше написано "тестируется" (само как-то?), потом стоит запятая и слово "далее" и про интеграционные тесты. Если эта твоя цитата не говорит что ты хочешь сказать, переформулируй, у меня очень плохо с телепатией.

P>>>Сколько бы я ни писал про интеграционные тесты, вам мерещится "погонять вручную"
P>·>У тебя интеграционные тесты тестируют каждый паттерн?
P>По числу юз кейсов. Все юз кейсы должны быть покрыты интеграционными тестами.
Давай цифири приведу. В типичном проекте какие мне доводилось наблюдать таких юзкекйсов порядка 100k при более-менее хорошо организованном тестировании. Каждый интеграционный тест вида "...UI workflow с навигацией от логина..." это порядка нескольких секунд, даже без учёта разворачивания и подготовки инфры. Прикинь сколько будет занимать прогон всех таких тестов. В реальности интеграцией можно покрыть от силы 1% кейсов. Если это, конечно, не хоумпейдж.

P>>>См выше, "никогда не будем загружать всю бд в память" — для этого кейса у вас ни одного теста, а у меня хоть какие то.
P>·>Ну потому что ты "1. был в курсе" и написал хоть какой-то тест. Т.е. они были не видны, как ты обещал, а у вас видимо на проде у вас что-то навернулось и ты это "увидел".
P>Покрыть все возможные комбинации фильтров тестом с бд — нереально. Вы можете покрыть ну 5, ну 10, ну 50, но если у вас фильтров на страницу — вы ошалеете. Здесь забег на тысячи комбинаций.
P>На каждую комбинацию накидать минимальную бд — уже мало реально.
Я тебе уже объяснял. Не надо накидывать бд на каждую комбинацию. Какие-то жалкие 30 (тридцать!) записей можно фильтровать миллиардом (2³⁰) уникальных способов, без учёта сортироваки.

P>Т.е. каждая комбинация это тесты вида "тащим откуда надо" + тесты вида "не тащим откуда не надо" коих много больше.
Не так, а так: для комбинации X выбираем эти 7 записей из 30.