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

P>>Будут. Но их всё равно нужно делать, т.к. никакие другие виды тестов их не заменяют, только кое где могут скомпенсировать.
·>Нужно, но как-то всё равно придётся покрывать остальные 99%. Вот тут и приходят на помощь моки и конф-тесты.

И вам всё еще непонятно, почему люди на проде тестируют? моки и конформационные тесты это не решение, а компенсация.
Вы отказываетесь идти дальше, и делать внятное покрытие e2e, и посмеиваетесь с тех, кто всё таки покрывает эти 99% как следует.

P>>Если у вас сложный воркфлоу, то его нечем протестировать, кроме вот этих e2e
·>Я тебе уже рассказал чем: моки и конф-тесты.

Пример у вас есть внятный? Мне непонятно, каким чудом моки репозитория помогут понять, что же с интеграцией не так.

Какой компоент системы вы собираетесь конф тестами покрывать?

P>>Не могут — моки по своей сути подменяют интеграцию отсебятиной.
·>Не только моки, но конф-тесты. Плюс соответствующий дизайн и процесс разработки.

Расскажите внятно, как мок репозитория поможет вам с интеграцией уровня приложения?

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

Невнятно, если честно. Общие слова "конф-тесты помогут"

P>>Итого, с ваших слов "задача сложная, нахер e2e, будем моки писать и сделаем вид, что это равноценная замена"
·>Не "нахер e2e", а "хрень получается с e2e".

Наоборот, e2e показывает те ошибки, которые проходят мимо ваших моков. Они показывают, что приложение склеено как положено.

P>>1 Аксиома — количество юнит-тестов и полуинтеграционных на моках никак не влияет на количество e2e. Никак, нисколько!
·>Тавтология. Я говорю о другом: количество e2e ограничивается доступными ресурсами. Чем меньше доступных e2e, тем больше приходится вкладываться в юнит и "полуинтеграционные".

Ну да — вы забили на интеграционные тесты.

P>> юниты и ваши полуинтеграционные пишите сколько надо, что бы быстро детектить мелочевку во время разработки
P>>2 e2e можно сделать так -
P>>- при билде — три самых частых
P>>- при деплое — три десятка самых частых
P>>- после деплоя — всё вместе, рандомно, то одно, то другое, с таким расчетом, что бы за день вы получили сведения что где может отвалиться
·>Не годится. Мы не можем релизиться только с тремя десятками сценариев. Надо проверять 100%.

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

P>>Итого — ваши 99% кейсов вы будете тестировать после деплоя. Боитесь делать это на проде — делайте на стейдже, деве и тд.
·>Не можем мы деплоить продукт оттестированный на 1%.

Вы уже это делаете. e2e всего то сделают видимыми проблемы в тех 99% которые ходили мимо ваших моков.

P>>3. каждые N минут запускаете `curl <stage>/manifest.test | run-test --random --url <stage>`
·> Т.е. качество продукта проверяем случайно. Это только для хоумпейджей годится.

Это способ выполнять те тесты, которые у вас вообще отсутствуют.

P>>Это полные тесты, где всё тащится медленно и реально — они нужны и вам, и мне. Если вы не учли этот кейс с нулём, то будет проблема. Ровно так же и у меня.
·>Ясен пень. Ты вообще читаешь что я пишу? Суть в том, что даже если вы учли кейс с нулём, то у вас всё равно будет проблема, а нас проблемы не будет.

Непонятно — как X может быть больше чем X + Y если и X и Y больше нуля?
Вы тестируете минимально, репозиторий + бд. Эта часть есть и у меня.
Только вы здесь останавливаетесь, а я, дополнительно, покрываю другим видом тестом несколько критичных кейсов.

И по вашему у меня покрытие будет хуже

Извините, но вы или не читаете, или вас чтото не то с логикой.

P>>И задача с фильтрами это про комбинации
·>Может я не понял твою задачу правильно, но в моём понимании, фильтры это задача которая сводится к одному компоненту, который может быть протестирован отдельно, а не комбинации различных компонент

Комбинации различных условий в фильтре, что дает нам ту самую data complexity, и проблемные комбинации вы будете узнавать только на проде, одну за другой

Собственно из за того, что никто вам заранее не выдал список проблемных комбинаций, нужно "придётся выдумывать правильную архитектуру и подходы контроля качества, чтобы риск неизвестного минимизировать"


P>>>>Я такого не говорил — это вы начали фантазировать, что придется ждать 5 минут и никак иначе не выйдет. Обоснования у вас никакого нет.
P>>·>Про 5 минут я не фантазировал, это твоя цитата.
P>>Я нигде не говорил, что юзер должен ждать 5 минут. Даже если профиль создаётся неделю, редактировать данные можно сразу.
·>Говорил, цитирую: чудесные вещи типа "после того, как сделал var u = service.CreateUser(...), нужно выждать не менее 5 минут перед service.UpdateUser(u, ...)".

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

Синклер привел пример "А в реальных системах встречаются ещё и чудесные вещи типа "после того, как сделал var u = service.CreateUser(...), нужно выждать не менее 5 минут перед service.UpdateUser(u, ...)", с которыми совсем всё плохо." И пример был про то, откуда берется время "задним числом"
Можно ли нажимать конопку, нельзя — у Синклера пример про то откуда будет браться время отличное от текущего.

P>>Вам нужно спросить у BA, какие данные надо сейчас, а какие — вообще.
·>Именно — вопросы за которые отвечает BA — это функциональные требования по сути.

Вот-вот. И если BA даёт добро — всё хорошо.

·>У тебя есть бизнес-функция "создать юзера". Результат который возвращается из этой функции — это тоже функциональный элемент. Результат говорит о том, что что-то произошло. Если ты вместо того, чтобы сделать саму операцию кладёшь что-то в очередь, то и результат функции меняется — вместо "что-то произошло", будет "что-то произойдёт".

Не вместо, а вместе. Все что нужно для редактирования — возвращаем сразу, BA так сказал. Всё, что для редактирования не нужно — вообще не возвращаем. А раз так, то можем поступать как проще — можно сразу, можно потом.
Уже в который раз уточняю, но вы всё равно видите чтото свое

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

Уже выяснили — это вы притянули пример Синклера который был совсем про другое.

P>>Зачем вам менять апишку для этого кейса?
·>Затем, что функция API "выполнить действие X" != "положить в очередь чтобы действие X когда-нибудь выполнилось (может быть)". Апишка просто обязана быть разной, чтобы не было таких "чудесных вещей", которые ты так любишь.

Вы путаете интерфейс и реализацию. API — create user, данные вернуть сразу — id, имя, фамилию. Всё не id-имя-фамилия, вы может создавать когда угодно, хоть с очередью, хоть без. Можете создать сразу — отлично. Не получается — ну и хрен с ним, абы id-имя-фамилия были дадены сразу


P>>>>

P>>>>п1 — паттерн тестируется на бд, далее —

интеграционными тестами

P>>>>...
P>>>>1. рабочий паттерн запроса — это проверяется

сначала руками, а потом тестом против бд минимально заполненой под задачу

P>>·>Я тебе в N+5й раз повторяю. Твоя формулировка неоднозначна. Напиши чётко.
P>>Я не в курсе, что именно вам непонятно
P>>Какой вопрос вы не озвочили — мне неизвестно.
P>>На мой взгляд что надо в моем ответе есть
P>>1. кто тестирует
·>Из слов "паттерн тестируется" неясно кем.

Если руками, что следует из выделеного, то какие варианты?

P>>3. какими тестами
·>Из слов "паттерн тестируется" неясно какими тестами

Я вам выделил, что бы виднее было.

P>>1. что делаем — сравниваем посимвольно, т.к. другого варианта нет — на одну задачу пилить ast на алгебраических типах данных это овердохрена
·>Другой вариант я рассказал — выполнить запрос на базе и заасертить результат.

Не работает — вы не знаете проблемной комбинации для фильтров. Знаете только что они есть и их хрензнаетсколькилион

P>>2. для чего делаем — что бы зафиксировать паттерн
·>Зачем?

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

P>>Вы до сих пор такой тест не показали
·>Это не покрывается тестами принципиально.

Покрывается. Я ж вам показал.

·>Только если у тебя какой-то очень частый случай и ты завязываешься на какую-то конкретную реализацию — а это значит, что у тебя тесты не будут тестировать даже регрессию.

Покажите пример регрессии, которая не будет обнаружена этим тестом.

·>Я никогда не просил объяснений, я просил код. Ибо по коду видны факты, а не твои фантазии. Так что не удивляйся, что твои объяснения являются словоблудием.

С кодом у вас два варианта
1. не будет работать
2. словоблудие

На примере — вам был даден код про структурную эквивалентность — вам надо знать, кто тестирует, какими тестами. Пять сообщений подряд и выделение болдом не помогло. Надеюсь, выделение H1 сделало это заметным

P>>Можно ограничить таблицы, из которых может или не может делаться джойн итд
·>Т.е. в тесте ты единственное что можешь зафиксировать, что в коде у тебя действительно стоит .top(10). И что? Зачем? Наличие .top(10) и так видно, оно уже и так явно прописано в коде.

Необязательно. Если я руками пишу весь запрос — то будет в коде явно. но запрос может и билдер создать.
Некоторые детали нужно фиксировать в тестах, что бы случайно залетевший дятел не разрушил цивилизацию.

P>>Кто вам скажет, что в ваших этих 30 записях есть все потенциально опасные или невалидные комбинации?
·>Это не решается тестами, никакими.

Решение — пост-условие. А вот тест который я показал, он всего то гарантирует сохранность этого пост-условия.

P>>Вручную всё равно придется проверять, это обязательный этап — с этого всё начинается.
·>Почему обязательный?

Если вы не можете сделать этого руками, то ваши попытки выразить это в коде и генерации данных будут иметь ту же особенность.

P>>Эта часть же как и у вас. Это именно интеграционный тест репозитория.
·>Т.е. тест репо+бд? У вас есть и такие тесты?

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

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

А разве я говорю, что это надо повсеместно?

P>>Проблемные комбинации вам неизвестны.
P>>Что будете в тест писать ?
·>В тесте по определению тестируется известное. Если ты считаешь твои тесты тестируют неизвестное — ты заблуждаешься.

Пост-условия похоже для вас пустой звук, вам это всё равно кажется тестом. Тест всего лишь гарантирует сохранность пост-условия

P>>Это же в операции известно, какие данные она возвращает. Если users.byId() то очевидно здесь один. А если users.where — вот тут а хрен его знает
·>Угу, именно, что "очевидно", но кто-то накосячил с фильтром в byId и у тебя внезапно не один... Т.е. если это и как-то проверяется, но не тестами.

Эта проблема и у вас будет. Например, вы тестируете на бд, где id это праймари кей, а в проде каким то чудом окажется другая схема, и id может иметь дубликаты
И решения и у меня, и у вас, для этого кейса будут одни и те же.

P>>У вас что, в требованиях позволено сдыхать при процессинге?
·>http 4xx или 5xx. Везде тупо возвращать только первые 10 записей и делать вид что так и надо — это какая-то студенческя поделка.

Вы снова чего то фантазируете.

P>>И тут мы узнаем... что тестами ничо не сделаешь. Гы-гы.
·>Тесты могут проверять только тривиальные свойства.

Нет, не могут. Так, как это утверждает т. Райса — вы true от false отличить не сможете. Можете потренироваться — тестами обнаружить функцию, которая всегда возвращает true. Валяйте.
Как напишете ваш тест — кидайте сюда, а я покажу, какая фукнция проходит ваш тест и не удовлетворяет условию
Для простоты, функция будет такой — () -> true, т.к. никаких параметров и тд и тд и тд
Как наиграетесь, приходите

P>>Соотвественно, гарантии у вас будут не с т.з. т.Райса, а с т.з. вероятностей
P>>- функция которая проходит тесты по таблице истинности подходит лучше, чем та, которая эти тесты не проходит
·>Мде... Ещё и вероятности пришли.

Они всегда были. см выше про т. Райса

P>>>>Поэтому вполне логично добавить пост-условие.
P>>·>Ну добавь. Тесты тут не причём. Сразу замечу, что тестировать наличие постусловий — это уже лютейший бред.
P>>У вас всё бред, чего вы не понимаете
·>Я понимаю на шаг вперёд.

Смотрите выше, текст выделен H1, как раз эту вашу способность и "демонстрирует"

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

Хрупкий — это я вам сразу сказал. Так я ж и не предлагаю посимвольное сравнение на все случаи жизни.

P>>·>Ок, переформулирую. Сложность у нас растёт ровно так же, как и у вас.
P>>В том то и дело, что растет экспоненциально.
·>И что ты этим хочешь сказать?

Да то, что искать тестами проблемные комбинации вы вспотеете. Нужно искать решение вне тестов.

P>>Первые запуски — руками. Потом автоматизируете и получаете интеграционный тест.
·>Зачем руками-то? В чём такая необходимость? И почему только первые запуски?

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

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

P>>Вы совсем недавно собирались все комбинации тестировать, разве нет?
·>Не все e2e комбинации, а комбинации конкретно данного куска кода, sut.

С фильтрами комбинаций столько, что солнце погаснет раньше ваших тестов.

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

Я то помню, а вы — нет. Смотрите, кто погаснет раньше,солнце, или перебор комбинаций на фильтрах.

P>>·>30 это было число записей, которые могут обеспечить 2³⁰ комбинаций. Тебе столько не хватает?
P>>Фильтры дают на десяток порядков больше комбинаций. В этом и проблем
·>Ну сделай 60 записей, будет как раз на десяток порядков больше комбинаций. В чём проблема-то?

Проблема в том, что бы генерить данные, нужно знать комбинации которые будут добавляться в набор данных

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

P>>Будут. Но их всё равно нужно делать, т.к. никакие другие виды тестов их не заменяют, только кое где могут скомпенсировать.
·>Нужно, но как-то всё равно придётся покрывать остальные 99%. Вот тут и приходят на помощь моки и конф-тесты.

И вам всё еще непонятно, почему люди на проде тестируют? моки и конформационные тесты это не решение, а компенсация.
Вы отказываетесь идти дальше, и делать внятное покрытие e2e, и посмеиваетесь с тех, кто всё таки покрывает эти 99% как следует.

P>>Если у вас сложный воркфлоу, то его нечем протестировать, кроме вот этих e2e
·>Я тебе уже рассказал чем: моки и конф-тесты.

Пример у вас есть внятный? Мне непонятно, каким чудом моки репозитория помогут понять, что же с интеграцией не так.

Какой компоент системы вы собираетесь конф тестами покрывать?

P>>Не могут — моки по своей сути подменяют интеграцию отсебятиной.
·>Не только моки, но конф-тесты. Плюс соответствующий дизайн и процесс разработки.

Расскажите внятно, как мок репозитория поможет вам с интеграцией уровня приложения?

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

Невнятно, если честно. Общие слова "конф-тесты помогут"

P>>Итого, с ваших слов "задача сложная, нахер e2e, будем моки писать и сделаем вид, что это равноценная замена"
·>Не "нахер e2e", а "хрень получается с e2e".

Наоборот, e2e показывает те ошибки, которые проходят мимо ваших моков. Они показывают, что приложение склеено как положено.

P>>1 Аксиома — количество юнит-тестов и полуинтеграционных на моках никак не влияет на количество e2e. Никак, нисколько!
·>Тавтология. Я говорю о другом: количество e2e ограничивается доступными ресурсами. Чем меньше доступных e2e, тем больше приходится вкладываться в юнит и "полуинтеграционные".

Ну да — вы забили на интеграционные тесты.

P>> юниты и ваши полуинтеграционные пишите сколько надо, что бы быстро детектить мелочевку во время разработки
P>>2 e2e можно сделать так -
P>>- при билде — три самых частых
P>>- при деплое — три десятка самых частых
P>>- после деплоя — всё вместе, рандомно, то одно, то другое, с таким расчетом, что бы за день вы получили сведения что где может отвалиться
·>Не годится. Мы не можем релизиться только с тремя десятками сценариев. Надо проверять 100%.

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

P>>Итого — ваши 99% кейсов вы будете тестировать после деплоя. Боитесь делать это на проде — делайте на стейдже, деве и тд.
·>Не можем мы деплоить продукт оттестированный на 1%.

Вы уже это делаете. e2e всего то сделают видимыми проблемы в тех 99% которые ходили мимо ваших моков.

P>>3. каждые N минут запускаете `curl <stage>/manifest.test | run-test --random --url <stage>`
·> Т.е. качество продукта проверяем случайно. Это только для хоумпейджей годится.

Это способ выполнять те тесты, которые у вас вообще отсутствуют.

P>>Это полные тесты, где всё тащится медленно и реально — они нужны и вам, и мне. Если вы не учли этот кейс с нулём, то будет проблема. Ровно так же и у меня.
·>Ясен пень. Ты вообще читаешь что я пишу? Суть в том, что даже если вы учли кейс с нулём, то у вас всё равно будет проблема, а нас проблемы не будет.

Непонятно — как X может быть больше чем X + Y если и X и Y больше нуля?
Вы тестируете минимально, репозиторий + бд. Эта часть есть и у меня.
Только вы здесь останавливаетесь, а я, дополнительно, покрываю другим видом тестом несколько критичных кейсов.

И по вашему у меня покрытие будет хуже

Извините, но вы или не читаете, или вас чтото не то с логикой.

P>>И задача с фильтрами это про комбинации
·>Может я не понял твою задачу правильно, но в моём понимании, фильтры это задача которая сводится к одному компоненту, который может быть протестирован отдельно, а не комбинации различных компонент

Комбинации различных условий в фильтре, что дает нам ту самую data complexity, и проблемные комбинации вы будете узнавать только на проде, одну за другой

Собственно из за того, что никто вам заранее не выдал список проблемных комбинаций, нужно "придётся выдумывать правильную архитектуру и подходы контроля качества, чтобы риск неизвестного минимизировать"


P>>>>Я такого не говорил — это вы начали фантазировать, что придется ждать 5 минут и никак иначе не выйдет. Обоснования у вас никакого нет.
P>>·>Про 5 минут я не фантазировал, это твоя цитата.
P>>Я нигде не говорил, что юзер должен ждать 5 минут. Даже если профиль создаётся неделю, редактировать данные можно сразу.
·>Говорил, цитирую: чудесные вещи типа "после того, как сделал var u = service.CreateUser(...), нужно выждать не менее 5 минут перед service.UpdateUser(u, ...)".

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

Синклер привел пример "А в реальных системах встречаются ещё и чудесные вещи типа "после того, как сделал var u = service.CreateUser(...), нужно выждать не менее 5 минут перед service.UpdateUser(u, ...)", с которыми совсем всё плохо." И пример был про то, откуда берется время "задним числом"
Можно ли нажимать конопку, нельзя — у Синклера пример про то откуда будет браться время отличное от текущего.

P>>Вам нужно спросить у BA, какие данные надо сейчас, а какие — вообще.
·>Именно — вопросы за которые отвечает BA — это функциональные требования по сути.

Вот-вот. И если BA даёт добро — всё хорошо.

·>У тебя есть бизнес-функция "создать юзера". Результат который возвращается из этой функции — это тоже функциональный элемент. Результат говорит о том, что что-то произошло. Если ты вместо того, чтобы сделать саму операцию кладёшь что-то в очередь, то и результат функции меняется — вместо "что-то произошло", будет "что-то произойдёт".

Не вместо, а вместе. Все что нужно для редактирования — возвращаем сразу, BA так сказал. Всё, что для редактирования не нужно — вообще не возвращаем. А раз так, то можем поступать как проще — можно сразу, можно потом.
Уже в который раз уточняю, но вы всё равно видите чтото свое

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

Уже выяснили — это вы притянули пример Синклера который был совсем про другое.

P>>Зачем вам менять апишку для этого кейса?
·>Затем, что функция API "выполнить действие X" != "положить в очередь чтобы действие X когда-нибудь выполнилось (может быть)". Апишка просто обязана быть разной, чтобы не было таких "чудесных вещей", которые ты так любишь.

Вы путаете интерфейс и реализацию. API — create user, данные вернуть сразу — id, имя, фамилию. Всё не id-имя-фамилия, вы может создавать когда угодно, хоть с очередью, хоть без. Можете создать сразу — отлично. Не получается — ну и хрен с ним, абы id-имя-фамилия были дадены сразу


P>>>>

P>>>>п1 — паттерн тестируется на бд, далее —

интеграционными тестами

P>>>>...
P>>>>1. рабочий паттерн запроса — это проверяется

сначала руками, а потом тестом против бд минимально заполненой под задачу

P>>·>Я тебе в N+5й раз повторяю. Твоя формулировка неоднозначна. Напиши чётко.
P>>Я не в курсе, что именно вам непонятно
P>>Какой вопрос вы не озвочили — мне неизвестно.
P>>На мой взгляд что надо в моем ответе есть
P>>1. кто тестирует
·>Из слов "паттерн тестируется" неясно кем.

Если руками, что следует из выделеного, то какие варианты?

P>>3. какими тестами
·>Из слов "паттерн тестируется" неясно какими тестами

Я вам выделил, что бы виднее было.

P>>1. что делаем — сравниваем посимвольно, т.к. другого варианта нет — на одну задачу пилить ast на алгебраических типах данных это овердохрена
·>Другой вариант я рассказал — выполнить запрос на базе и заасертить результат.

Не работает — вы не знаете проблемной комбинации для фильтров. Знаете только что они есть и их хрензнаетсколькилион

P>>2. для чего делаем — что бы зафиксировать паттерн
·>Зачем?

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

P>>Вы до сих пор такой тест не показали
·>Это не покрывается тестами принципиально.

Покрывается. Я ж вам показал. Только решение и покрытие это разные вещи. В данном случае решение — постусловие. А тестами фиксируем, что бы не убежало

·>Только если у тебя какой-то очень частый случай и ты завязываешься на какую-то конкретную реализацию — а это значит, что у тебя тесты не будут тестировать даже регрессию.

Покажите пример регрессии, которая не будет обнаружена этим тестом.

·>Я никогда не просил объяснений, я просил код. Ибо по коду видны факты, а не твои фантазии. Так что не удивляйся, что твои объяснения являются словоблудием.

С кодом у вас два варианта
1. не будет работать
2. словоблудие

На примере — вам был даден код про структурную эквивалентность — вам надо знать, кто тестирует, какими тестами. Пять сообщений подряд и выделение болдом не помогло. Надеюсь, выделение H1 сделало это заметным

P>>Можно ограничить таблицы, из которых может или не может делаться джойн итд
·>Т.е. в тесте ты единственное что можешь зафиксировать, что в коде у тебя действительно стоит .top(10). И что? Зачем? Наличие .top(10) и так видно, оно уже и так явно прописано в коде.

Необязательно. Если я руками пишу весь запрос — то будет в коде явно. но запрос может и билдер создать.
Некоторые детали нужно фиксировать в тестах, что бы случайно залетевший дятел не разрушил цивилизацию.

P>>Кто вам скажет, что в ваших этих 30 записях есть все потенциально опасные или невалидные комбинации?
·>Это не решается тестами, никакими.

Решение — пост-условие. А вот тест который я показал, он всего то гарантирует сохранность этого пост-условия.

P>>Вручную всё равно придется проверять, это обязательный этап — с этого всё начинается.
·>Почему обязательный?

Если вы не можете сделать этого руками, то ваши попытки выразить это в коде и генерации данных будут иметь ту же особенность.

P>>Эта часть же как и у вас. Это именно интеграционный тест репозитория.
·>Т.е. тест репо+бд? У вас есть и такие тесты?

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

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

А разве я говорю, что это надо повсеместно?

P>>Проблемные комбинации вам неизвестны.
P>>Что будете в тест писать ?
·>В тесте по определению тестируется известное. Если ты считаешь твои тесты тестируют неизвестное — ты заблуждаешься.

Пост-условия похоже для вас пустой звук, вам это всё равно кажется тестом. Тест всего лишь гарантирует сохранность пост-условия
А вот пост условие отработаетт для всего выхлопа, сколько бы раз вы ни вызывали его

P>>Это же в операции известно, какие данные она возвращает. Если users.byId() то очевидно здесь один. А если users.where — вот тут а хрен его знает
·>Угу, именно, что "очевидно", но кто-то накосячил с фильтром в byId и у тебя внезапно не один... Т.е. если это и как-то проверяется, но не тестами.

Эта проблема и у вас будет. Например, вы тестируете на бд, где id это праймари кей, а в проде каким то чудом окажется другая схема, где id может иметь дубликаты
И решения и у меня, и у вас, для подобных кейсов будут одни и те же.

P>>У вас что, в требованиях позволено сдыхать при процессинге?
·>http 4xx или 5xx. Везде тупо возвращать только первые 10 записей и делать вид что так и надо — это какая-то студенческя поделка.

Вы снова чего то фантазируете.

P>>И тут мы узнаем... что тестами ничо не сделаешь. Гы-гы.
·>Тесты могут проверять только тривиальные свойства.

Нет, не могут. Так, как это утверждает т. Райса — вы true от false отличить не сможете. Можете потренироваться — тестами обнаружить функцию, которая всегда возвращает true. Валяйте.
Как напишете ваш тест — кидайте сюда, а я покажу, какая фукнция проходит ваш тест и не удовлетворяет условию
Для простоты, функция будет такой — () -> true, т.к. никаких параметров и тд и тд и тд
Как наиграетесь, приходите

P>>Соотвественно, гарантии у вас будут не с т.з. т.Райса, а с т.з. вероятностей
P>>- функция которая проходит тесты по таблице истинности подходит лучше, чем та, которая эти тесты не проходит
·>Мде... Ещё и вероятности пришли.

Они всегда были. см выше про т. Райса

P>>>>Поэтому вполне логично добавить пост-условие.
P>>·>Ну добавь. Тесты тут не причём. Сразу замечу, что тестировать наличие постусловий — это уже лютейший бред.
P>>У вас всё бред, чего вы не понимаете
·>Я понимаю на шаг вперёд.

Смотрите выше, текст выделен H1, как раз эту вашу способность и "демонстрирует"

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

Хрупкий — это я вам сразу сказал. Так я ж и не предлагаю посимвольное сравнение на все случаи жизни.

P>>·>Ок, переформулирую. Сложность у нас растёт ровно так же, как и у вас.
P>>В том то и дело, что растет экспоненциально.
·>И что ты этим хочешь сказать?

Да то, что искать тестами проблемные комбинации вы вспотеете. Нужно искать решение вне тестов.

P>>Первые запуски — руками. Потом автоматизируете и получаете интеграционный тест.
·>Зачем руками-то? В чём такая необходимость? И почему только первые запуски?

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

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

P>>Вы совсем недавно собирались все комбинации тестировать, разве нет?
·>Не все e2e комбинации, а комбинации конкретно данного куска кода, sut.

С фильтрами комбинаций столько, что солнце погаснет раньше ваших тестов.

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

Я то помню, а вы — нет. Смотрите, кто погаснет раньше,солнце, или перебор комбинаций на фильтрах.

P>>·>30 это было число записей, которые могут обеспечить 2³⁰ комбинаций. Тебе столько не хватает?
P>>Фильтры дают на десяток порядков больше комбинаций. В этом и проблем
·>Ну сделай 60 записей, будет как раз на десяток порядков больше комбинаций. В чём проблема-то?

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