Здравствуйте, ·, Вы писали:
P>>Это и есть пересказ всего, что изложено в clean architecture. Я уже приводил пример, вы прицепились к проверке sql и до сих пор успокоиться не можете.
P>>Какой смысл приводить еще один пример, если вы еще на предыдущий продолжаете наскакивать?
·>Действительно. Какой смысл искать верное решение задачи, если в предыдущем были ошибки. Отличная логика!
Вы пока ошибок не показали. Основная ваша придирка в том, что структурная эквивалентность не нужна, хрупкая, итд — при этом альтернативы такому решению у вас нет.
P>>Очень просто — редактироавние после записи нужно для конкретных целей, например — что бы администратор мог подправить свойства только что созданного юзера, а не ждать пять минут.
·>Это вроде очевидное требование. Необходимость пользователям ждать по пять минут перед тем как нажать кнопочку — должно быть серьёзно обоснованно и обговорено с заказчиком. Как ты это вообще представляешь?
Вы снова с колокольни? Ничего ждать не надо — в том то и особенность. И всё работает. Потому как данные по пользователю делятся на две большие части — те, что нужны сейчас, и те, что просто нужны.
Вот например — под нового сотрудника аккаунт создаётся заранее. Здесь заботиться о том, что бы всё-всё-всё(и все гуиды редактировали руками, ага) было доступно к редактированию через 50мс — требование неадекватное.
А вот изменение имени пользователя спустя секунду после создания — очень даже адекватно.
P>>Если ваш бизнес аналиитк затребовал вообще всё такое — то вы приплыли.
·>Я не в курсе что такое "паблик кей спейса юзера".
public ssl key — ничего военного. Пересоздавать этот кей спустя секунду после создания занятие абсолютно бессмысленное. А вас послушать, так окажется что любые данные ассоциированые с пользователем могут меняться сразу же, включая гуиды ссылок на любую глубину связности.
P>>·>Где находим? Как проверяем? Когда проверяем?
P>>Извините, но вам стоит читать внимательнее. Я последее время слишком часто цитирую самого себя. Не можете удерживать контекст — чего вам неймется, "в интернете ктото неправ"?
·>Ты ни разу не ответил прямо на этот вопрос.
Цитирую себя N+1й и N+2q разы
п1 — паттерн тестируется на бд, далее — интеграционными тестами
...
1. рабочий паттерн запроса — это проверяется сначала руками, а потом тестом против бд минимально заполненой под задачу
Я вот почему то уверен, что несмотря на эти цитаты вы еще месяц или два будете мне доказывать, что я тестирую только юнит-тестами.
P>>Все код был даден, отмотайте и посмотрите, это всё та же структурная эквивалентность запроса к бд.
·>Мы рассмотрели этот пример, ты вроде даже признал, что там лажа.
Пример недостаточно информативный. А вот сам подход — проверять построение запроса — очень даже хороший.
P>>маппер — по json строит конкретный запрос, createUser
P>>паттерн — основа этого запроса
·>что за основа? Запроса какого? sql?
Какого угодно. Если вам для запроса данных нужна цепочка джойнов или вложеный запрос — то это и есть паттерн. А дальше наш билдер должен гарантировать, что для любых возможных параметров, а не только тех, что вы косвенно подкинули в тестах, запрос будет соответствовать заданному паттерно — цепочка джойнов, вложеный запрос, итд итд итд.
А так же надо учесть вещи вида "не делает то чего делать не должен".
P>>трансформация — часть маппера, трансформируем json в нужный нам вид, на выходе — делаем обратное преобразование.,
·>Трансформация? Обратная? А что такое transformations? out:...? Это было частью pattern в твоём сниппете. Тут ты говоришь, что это часть маппера.
Путаница из за того, что есть паттерн запроса и паттерн в тесте это похожее, но разное
Вот смотрите
const request = Builder.createUser(...args);
expect(request).to.deep.eq({
in: fn1,
out: fn2,
sql: ' наш конкретный запрос ',
args: [ параметры для запроса]
})
Все что передается в eq — паттерн для теста. А ' наш конкретный запрос' тут проверяем паттерн запроса к бд. Синклер говорит, что эффективнее AST. Это конечно же так. Только пилить АСТ под частный случай я не вижу смысла, во первых. А во вторых, по похожей схеме мы можем проверять запросы любого вида http, rest, rpc, graphql, odata итд.
Например, для эластика у вас будет обычный http запрос.
Можно точно так же проверять запросы к ORM. Это решает проблемы с джигитам "я быстренько, там всё просто"
P>>Я вам продолжаю приводить тот же самый пример — фильтры, когда из за ошибки в построении запроса вгружается вся бд. Вы его усиленно игнорируете.
·>Я не игнорирую, я уже где-то месяц назад написал как его покрыть нормальным тестом. Это ты игнорируешь мои ответы.
Вы показали примитивные тесты вида "положили в таблицу, проверили, что нашли положенное". А как протестировать "не нашли неположенного" или "не начали вгружать вообще всё" — вы такого не показали.
И то, и другое вашими примитивными тестами не решается.
Частично можно решить на боевой бд или приравненой к ней, но только для тех данных что есть сейчас. Как это сделать для тех данных, что у нас будут через год — загадка.
·>Он выполняется косвенно, через кучу слоёв: "когда у нас дошла очередь интеграционного тестирования, где (медленно!) тащатся реальные данные из реальной базы, выполняется (медленный!) UI workflow с навигацией от логина до этого отчёта, и т.п.".
·>Т.е. либо у тебя такие тесты будут гонятся неделями, либо ты сможешь покрыть только ничтожную долю комбинаций этих конкретных запросов.
·>В моём случае тесты выполняют только связку репо+бд и там можно гонять на порядки больше комбинаций.
Связка репо+бд называется интеграционный тест. Вы такими тестами собираетесь покрывать все комбинации
И щас же будете рассказывать, что вы имели в виду чтото другое.
Сколько бы вы комбинаций не всунули в репо+бд тесты — Data Complexity вам такими тестами не сбороть, ну никак.
Но вы продолжаете это пытаться.
Интеграционные нужны для проверки, что репо умеет работать с бд, а вовсе не для проверок комбинаций. Для проверок комбинаций есть другие методы, гораздо более эффективные.
P>>А раз покрыть все комбинации не получится, то незачем и пытаться — нужно переложить критические кейсы на другие методы.
·>Вот и неясно зачем вы пытаетесь это перекладывать на эти ваши странные бесполезные тесты, т.к. нужно другие методы использовать.
Вы только что "показали" — для проверок комбинций использовать интеграционный тест репо+бд
P>>И как вы протестируете, что у вас невозможна ситуация, что прод вгружает вообще всё?
·>Вы тоже не можете это _протестировать_. Просто ещё этого не поняли.
Могу. Например, для тестов которые тянут больше одной строки могу просто затребовать `LIMIT 10`.
P>>·>Именно, для этого и нужны тесты репо+бд. А при наличии таких тестов писать тесты ещё и на построение запросов — неясно зачем.
P>>Я ж вам говорил — некорректный запрос в тестах может выдавать корректный результат. И примеры привел.
·>Я примеров не видел. Я видел "объяснения".
Мы уже проходили — код всегда частный случай, на что у вас железный аргумент "у нас такой проблемы быть не может принципиально"
P>>Валидность вообще всех запросов проверить не выйдет — та самая data complexity. Зато можно проверить известные проблемы для тех случаев, когда точная комбинация входа неизвестна.
·>Как? Ты это Проблему Останова решил тестами?
Не я, а вы. Это у вас комбинации покрываются repo+db тестами. А мне достаточно гарантировать наличие свойства запроса. см пример с LIMIT 10 выше. И это свойство сохранится на все времена, а потому проблема останова для меня здесь неактуальна.
·>Ложная альтернатива. Ты "забыл" вариант: гонять через базу все возможные кейсы что есть в бд прода, или нам известно, что такие будут.
Скажите честно, сколько уникальных тестов у вас всего в проекте, всех уровней, видов, итд? И сколько у вас таблиц и связей в бд?
Моя оценка — уникальных тестов у вас самое большее 1000 помножить на число девелоперов. А тестов "комбинаций" из этого будет от силы 1%.
Итого — сколько тестов , таблиц, связей?р
P>>·>Я до сих пор не понимаю почему у тебя есть проблема с загрузкой всей бд в память, решается же элементарно.
P>>Вы до сих пор не показали решения. Комбинация параметров вам неизвестна. Действуйте.
·>Только после вас.
Я уже привел кучу примеров. А вы всё никак.
P>>В зависимости от задачи. Например — двойная фильтрация. Часть фильтров в самом запросе, ограничивают выборку, не параметризуются, часть — параметры для фильтрации оставшегося.
P>>Теперь что бы вы не подкидывали в фильтр, у вас никогда не будет кейса "вгрузить всё"
·>И что ты будешь ассертить в твоём тесте? sql.contains("LIMIT 1000")? 
Зачем contains ? Проверяться будет весь паттерн запроса, а не его фрагмент.
P>>Это именно ваш подход — записать три значения в бд и надеяться что этого хватит. А как протестировать "запрос не тащит откуда не надо" вы не показали.
·>Показал. Запрос должен из условных трёх записей выбирать только условно две.
Не работает. Фильтры могут тащить из херовой тучи таблиц, связей итд. Вам надо самое меньшее — заполнение всех возможных данных, таблиц, связей и тд. И так на каждый тест.
У вас здесь сложность растет экспоненциально.
P>>Вы дурака валяете? deep.eq.pattern это тест для п2. Тесты для п1 — обычные интеграционные.
·>Я читаю что написано.
Ну сейчас то понятно, что интеграционные никто не отменял, или еще месяц-два будете это игнорировать?
P>>По числу юз кейсов. Все юз кейсы должны быть покрыты интеграционными тестами.
·>Давай цифири приведу. В типичном проекте какие мне доводилось наблюдать таких юзкекйсов порядка 100k при более-менее хорошо организованном тестировании. Каждый интеграционный тест вида "...UI workflow с навигацией от логина..." это порядка нескольких секунд, даже без учёта разворачивания и подготовки инфры. Прикинь сколько будет занимать прогон всех таких тестов. В реальности интеграцией можно покрыть от силы 1% кейсов. Если это, конечно, не хоумпейдж.
100к юзкейсов протестировать сложно, а написать легко? Чтото тут не сходится. Вы вероятно юзкейсом называете просто разные варианты параметров для одного и того же вызова контроллера.
P>>На каждую комбинацию накидать минимальную бд — уже мало реально.
·>Я тебе уже объяснял. Не надо накидывать бд на каждую комбинацию. Какие-то жалкие 30 (тридцать!) записей можно фильтровать миллиардом (230) уникальных способов, без учёта сортироваки.
Похоже, вы точно не понимаете data complexity.
Эти 30 комбинаций разложить по таблицам и колонкам и окажется в среднем около нуля на большинстве комбинаций фильров.
P>>Т.е. каждая комбинация это тесты вида "тащим откуда надо" + тесты вида "не тащим откуда не надо" коих много больше.
·>Не так, а так: для комбинации X выбираем эти 7 записей из 30.
См выше — вы разложили 30 записей по таблицами и колонкам и в большинстве случаев у вас выходит 0 значений. А потому 7 из 30 это ни о чем.
Соответственно, пускаете фильтр на проде, и приложение вгружает базу целиком.
