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

P>>>Чем ваши acceptance и smoke отличаются от e2e ?
P>·>acceptance и smoke — подвиды e2e. Первые запускаются до деплоя, вторые запускаются сразу после. Если smoke-тест падает — делается откат к предыдущей версии.
P>Итого — e2e у вас есть.
Есть. Но 99% этих тестов — с моками, которые ты так ненавидишь. Без моков только smoke — коротый тестирует этот самый 1% (по самым оптимистичным оценкам, скорее всего даже сильно меньше).

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


P>>>·>У тебя память как у рыбки. Цитирую:
P>>>·>

P>>>·>·>потенциально может быть null — ты не дождёшься окончания.
P>>>·>

P>>>Я шота не понял ваш аргумент.
P>·>В смысле ты не понял что ты хотел сказать своей цитатой? Ничем помочь не могу.
P>Это ваша цитата http://rsdn.org/forum/design/8701337.1

Автор: ·
Дата: 29.02.24

Я уже совершенно перестал поспевать за полётом твоей мысли. Ты на эту мою цитату ответил что-то уже. Видимо тогда ты понял, а сейчс уже не понял? Перечитай ещё раз. Если что неясно, задавай вопросы.

P>Вот мы и узнали, у кого память как у рыбки. И уже в который раз
Угу, наконец-то и ты себя узнал.

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

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

P>>>Вы зачем то снова пустились в фантазирование. Юзер у вас что, на бакенде сидит? Нет ведь. Он в каком то клиентском приложении. Вот там и ищите фоновый процессинг.
P>·>В смысле фоновой процессинг в 3rd party внешней системе? Ну тогда это их проблема, поведение нашего api задокументировано.
P>Т.е. вы не понимаете, что фронтенд, мобайл, десктоп может быть частью вашей системы?
Тогда не понимаю проблему. В нашем клиенте тоже источник времени который можно мочить, а не дух святой.

P>>>В проде указали 30 минут, а из за мержа конфигов у вас стало 300, например, потому что это дефолтное значение. Это снова пример проблемы которая идет мимо ваших моков.
P>·>Дифф конфигов прода и теста покажет отстутствие параметра.
P>Как то слишком категорично. Думаете вы один умеете конфиги сравнивать?
P>Посмотрите в коде — где у вас дефолтные значения для параметров по умолчанию?
Ээээ... В коде.

P>У вас что, все 100500 возможных констант исключительно в конфигах?
P>Дефолтные значения могут подкидываться даже либами, если вы забудете подкинуть значение.
Не понял. Когда прогоняешь acceptance тесты, ты прогоняешь тесты для системы версии <длинный sha>. Ровно этот же sha и деплоится на прод и гарантированно имеет все те же либы и код, с точностью до бита. Следовательно и константы имеют идентичное значение. В эпоху докер-имаджей иметь такие проблемы как у вас — должно быть просто стыдно.

P>>>Именно что в мониторинге, а не в ваших тестах на моках. И только под нагрузкой.
P>·>Угу, и?
P>Мы только что выяснили, что моками вы никаких гарантий дать не можете — все равно придется ждать деплоя на прод и смотреть в мониторинг когда нагрузка стала той самой
Зачем? Нагрузочное тестирование можно и в отдельном перф-енве сделать. Путём ускоренного проигрывания событий из вчерашнего прода.

P>>>Вы до сих пор название топика не вкурили? dependency rejection это целиком про дизайн.
P>·>Это вроде давно обсудили. Ты потом переключился на моки.
P>Это все в контексте дизайна который определяется тестами. Написали под моки — значит пропихивать зависимости так, а не иначе. И всё, приплыли.
Ты так говоришь, будто это что-то плохое.

P>>>Построили дизайн под моки — естественно, кроме моков ничего и не будет.
P>·>Нет никакого дизайна под моки. Есть внешние системы — будут моки.
P>У вас именно так — вы считаете моки единственным инструментом для работы с зависимостями.
Других ты не смог предложить.

P>·>Мде. Видимо вообще вы с Sinclair не вдупляете что такое глобальные переменные. Поэтому и используете, не видя разницы.
P>Скорее это вы почему то не понимаете, что мир не сводится к вашему проекту.
Так вы сами себе в ногу стреляете своим DateTime.Now().

P>Подозреваю, вы и под глобальными переменными вы подразумеваете чтото другое.
А что я должен подразумевать по-твоему?

P>>>Да, вы эту сказку много раз повторяли — у вас мониторинг любую даже гипотетически возможную проблему обнаруживает сразу.
P>·>Это ты опять врёшь, я такое не говорил. А у вас тестинг занимается обнаружением любых гипотетических проблем, да?
P>Очевидно, что нет. Только зафиксированых на момент написания теста. И этих проблем он обнаруживает на два порядка больше мониторинга.
А разница в том, что мы, благодаря мокам и дизайну, можем обнаружить все эти зафиксированные проблемы ещё до планирования релиза, а вы — только после как "Юзеры репортают проблемы". Зато всё по фаулеру!

P>>>Вы что, повсюду в бизнес-логике пишете "if user.isTest() " ? Очень вряд ли. Интеграция для тестового юзера и реального будет та же самая. Соответственно, обнаруженные проблемы практически наверняка будут играть и для тестовых юзеров.
P>·>Т.е. в конце месяца ты узнаешь, что у вас сломано создание statement? Это уже очень поздно. Ты получишь злобное письмо как минимум от каждого десятого юзера.
P>Вы снова занялись фантазированием. Вот проверили вы список проблем со значением в конфиге, условно, 5 минут.
P>А потом на проде вылезла новая проблема ровнёхонько через месяц
P>- например, задачи на создание стейтмента создаются, но висят ибо очередь забита чего у вас в тестах не было из за недостаточной загрузки
Забитость очереди, ещё раз, тривиально детектится мониторингом.

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

P>>>Мы уже выясняли — вы держите только ту часть acceptance, которую можно выполнить за полчаса. А другие на идут дальше этого 1%
P>·>Нет, мы дизайним так, чтобы любой acceptance можно было выполнить за пол часа, даже для сценариев которые требуют sleep(1 month). Время-то мочёное.
P>Значит это никакой не acceptance если вы мокаете время. Вероятно, это ваша местная специфика.
С чего это? Acceptance это не про моки, а про good to go.

P>Повторяюсь уже
P>

P>new controller(параметры)
P>

P>Отдельные части это технически вообще как юнит-тесты.
Т.е. поднимается вся инфра? Ведь контроллер может использовать ВСЁ.
Что за "параметры"? Моки, ведь, да?

P>>>Что вам непонятно было в прошлый раз? Вы продолжаете задавать один и тот же вопрос, получаете один и тот же ответ. Чего вы ждете?
P>·>Что вам непонято было в прошлый раз? Вы продолжаете гнать пургу про запуск тестов в проде случайным образом в случайные моменты времени.
P>Прогон тестов на проде это не моя придумка. Уже лет десять назад было довольно популярной практикой.
Где? Есть статьи?

P>>>Вы же сами сказали — у вас ажно 1% покрыт. Вот на остальные 99% и нужно придумать чтото получше чем есть у вас.
P>·>smoke-тестом — да, ~1%. А больше и не надо.
P>А acceptance сколько покрывает?
Почти всё. Но с моками.

P>>>Теорема Райса с вами не согласна. Нету у вас 100% надежного способа гарантировать даже true из boolean.
P>·>Верно, т.е. эти ваши тесты ничего нового не дадут.
P>мой подход сродни статической типизации — на него теорема Райса не действует


P>·>Я же объяснил, для управления этим используются другие средства вместо прогона тестов.
P>Вы эти другие пока не показали. Вам удобнее обсуждать тесты отдельно от дизайна.
Создавай новый топик, задавай вопросы.

P>>>Вашу интеграцию тестируют acceptance и smoke. я вот не удивлюсь, если окажется что ваши acсeptance это ровно то же, что и e2e
P>·>Зависит от терминологии. Acceptance работают с моками внешних систем. Это считается как e2e?
P>Условно, да
Ну ок. Т.е. мы тестируем с моками, без прода. Всё ок.

P>>>А также те, для которых тесты существуют, но причин более одной, разница прода и стейджа итд.
P>·>Разница в чём? У бинарников полное совпадение до бита. Отличаться могут только конфиги, и это контролируется diff-ом.
P>Нагрузка, данные, энвайрмент, время, сеть — отсюда и лезет недетерминизм.
Нагрузка и данные недетерминизм не создают.
Энвайрмент, время — он у вас лезет, потому что вы сами его создаёте этим же своим DateTime.Now() и бесконтрольными конфигами.
Сеть — это по сути многопоточка. Самое сложное, конечно. Но тестами оно вообще никакими не лечится, только общим подходом.

P>·>Если только недетерминизм есть какой-то, из-за ошибок в многопоточке, например. Но такое тестами и не найти, тем более на проде. Если только случайно повезёт.
P>Именно для этого некоторые конторы в момент максимальной нагрузки запускают тесты прода. Это не шутка.
P>Таким образом тестируется система в нагрузке.
Жуть.

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

P>>>Комбинаций у вас нет. Так?
P>·>Комбинации есть ровно те, что что и у вас.
P>Так и у меня их нет. И мой подход основан на пост-условиях. Это почти что статическая типизация, с некоторым упрощением.
Ага-ага Почти беременна, с некоторым упрощением.

P>А вот тесты здесь играют совсем другую роль — они фиксируют наличие пост-условия.
Не фиксируют, наивый юноша.

P>>>Структурная эквивалентность, синтаксис теореме Райса не подчиняются.
P>·>Это и означает, что ваш тест проверяет, что works as coded. Абсолютно бесполезное занятие.
P>work as coded это если копировать sql из приложения в тесты.
Так ты не стесняйся, покажи свой пример кода для которого ты показал свой тест с pattern. Получится ровно копипаст.

P>А если в приложении билдер, а в тестах — его выхлоп на конкретных параметрах, то мы напрямую проверяем маппер — о большинстве проблем вы узнаете еще до запуска на реальной базе данных
Именно, что у тебя ровно то же, что и у меня: "на конкретных параметрах". ЧТД. Статическая типизация, май год! А как дышал...

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

P>>>Ваши тесты ничего не дают без знания конкретных комбинаций на которых можно отработать тест
P>·>Ваши тоже.
P>Вы пока не смогли пример адекватный привести, который сломает хотя бы примитивный limit 10.
Привёл в ответе Sinclair с ?:-оператором.

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

P>>>В том то и дело, что не даёт. У вас нет комбинаций, а потому проверяние количества записей смысла не имеет — в тестовой базе просто нет тех самых данных.
P>·>У меня ровно те же комбинации, что будут и в твоих тестах. Отличается только часть в ассертах. Вместо проверки синтаксиса — sql-код запускается и валидируется интересный с тз бизнеса результат.
P>Комбинации в бд не показывают проблему. Следовательно, вы вытащите её на прод.
Если у меня не показывают, то и у тебя не показывают. Об чём спор-то?

P>>>В прод коде только билдер. Откуда копипаста взялась?
P>·>В прод-коде у тебя будет реализация, "LIMIT 10", в тест-коде у тебя будет .eq("...LIMIT 10").
P>.
P>Не будет. Нигде в коде приложения нет явного LIMIT 10. Лимит вычисляется билдером. Будет ли это LIMIT или подзапрос с нужным выражением — дело десятое.
P>Важно, что лимит будет обязательно. И мне не надо перебирать всю таблицу истинности билдера на интеграционных тестах.
Главное верить, и свечку поставить.

P>>>Это всё из другого проекта, я им больше не занимаюсь
P>·>Ну сделай набросок, чтобы понятно было.
P>Все что мог, я вам показал. Что еще нужно? Запрос вы видите. Он собирается из разных частей. Каждая тестируется по отдельности.
P>Главное что бы структура была корректной.
Чтобы был конкретный код, в который можно пальчиком тыкнуть. Иначе это твоё словоблудие уже надоело.

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

P>>>Известно какое — в память не влазит
P>·>Что не влазит? Кому не влазит? Нихрена не понял.
P>Результат запроса не влазит в память.
Причём тут isOdd?

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

P>>>Чем ваши acceptance и smoke отличаются от e2e ?
P>·>acceptance и smoke — подвиды e2e. Первые запускаются до деплоя, вторые запускаются сразу после. Если smoke-тест падает — делается откат к предыдущей версии.
P>Итого — e2e у вас есть.
Есть. Но 99% этих тестов — с моками, которые ты так ненавидишь. Без моков только smoke — коротый тестирует этот самый 1% (по самым оптимистичным оценкам, скорее всего даже сильно меньше).

P>>>·>У тебя память как у рыбки. Цитирую:
P>>>·>

P>>>·>·>потенциально может быть null — ты не дождёшься окончания.
P>>>·>

P>>>Я шота не понял ваш аргумент.
P>·>В смысле ты не понял что ты хотел сказать своей цитатой? Ничем помочь не могу.
P>Это ваша цитата http://rsdn.org/forum/design/8701337.1

Автор: ·
Дата: 29.02.24

Я уже совершенно перестал поспевать за полётом твоей мысли. Ты на эту мою цитату ответил что-то уже. Видимо тогда ты понял, а сейчс уже не понял? Перечитай ещё раз. Если что неясно, задавай вопросы.

P>Вот мы и узнали, у кого память как у рыбки. И уже в который раз
Угу, наконец-то и ты себя узнал.

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

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

P>>>Вы зачем то снова пустились в фантазирование. Юзер у вас что, на бакенде сидит? Нет ведь. Он в каком то клиентском приложении. Вот там и ищите фоновый процессинг.
P>·>В смысле фоновой процессинг в 3rd party внешней системе? Ну тогда это их проблема, поведение нашего api задокументировано.
P>Т.е. вы не понимаете, что фронтенд, мобайл, десктоп может быть частью вашей системы?
Тогда не понимаю проблему. В нашем клиенте тоже источник времени который можно мочить, а не дух святой.

P>>>В проде указали 30 минут, а из за мержа конфигов у вас стало 300, например, потому что это дефолтное значение. Это снова пример проблемы которая идет мимо ваших моков.
P>·>Дифф конфигов прода и теста покажет отстутствие параметра.
P>Как то слишком категорично. Думаете вы один умеете конфиги сравнивать?
P>Посмотрите в коде — где у вас дефолтные значения для параметров по умолчанию?
Ээээ... В коде.

P>У вас что, все 100500 возможных констант исключительно в конфигах?
P>Дефолтные значения могут подкидываться даже либами, если вы забудете подкинуть значение.
Не понял. Когда прогоняешь acceptance тесты, ты прогоняешь тесты для системы версии <длинный sha>. Ровно этот же sha и деплоится на прод и гарантированно имеет все те же либы и код, с точностью до бита. Следовательно и константы имеют идентичное значение. В эпоху докер-имаджей иметь такие проблемы как у вас — должно быть просто стыдно.

P>>>Именно что в мониторинге, а не в ваших тестах на моках. И только под нагрузкой.
P>·>Угу, и?
P>Мы только что выяснили, что моками вы никаких гарантий дать не можете — все равно придется ждать деплоя на прод и смотреть в мониторинг когда нагрузка стала той самой
Зачем? Нагрузочное тестирование можно и в отдельном перф-енве сделать. Путём ускоренного проигрывания событий из вчерашнего прода.

P>>>Вы до сих пор название топика не вкурили? dependency rejection это целиком про дизайн.
P>·>Это вроде давно обсудили. Ты потом переключился на моки.
P>Это все в контексте дизайна который определяется тестами. Написали под моки — значит пропихивать зависимости так, а не иначе. И всё, приплыли.
Ты так говоришь, будто это что-то плохое.

P>>>Построили дизайн под моки — естественно, кроме моков ничего и не будет.
P>·>Нет никакого дизайна под моки. Есть внешние системы — будут моки.
P>У вас именно так — вы считаете моки единственным инструментом для работы с зависимостями.
Других ты не смог предложить.

P>·>Мде. Видимо вообще вы с Sinclair не вдупляете что такое глобальные переменные. Поэтому и используете, не видя разницы.
P>Скорее это вы почему то не понимаете, что мир не сводится к вашему проекту.
Так вы сами себе в ногу стреляете своим DateTime.Now().

P>Подозреваю, вы и под глобальными переменными вы подразумеваете чтото другое.
А что я должен подразумевать по-твоему?

P>>>Да, вы эту сказку много раз повторяли — у вас мониторинг любую даже гипотетически возможную проблему обнаруживает сразу.
P>·>Это ты опять врёшь, я такое не говорил. А у вас тестинг занимается обнаружением любых гипотетических проблем, да?
P>Очевидно, что нет. Только зафиксированых на момент написания теста. И этих проблем он обнаруживает на два порядка больше мониторинга.
А разница в том, что мы, благодаря мокам и дизайну, можем обнаружить все эти зафиксированные проблемы ещё до планирования релиза, а вы — только после как "Юзеры репортают проблемы". Зато всё по фаулеру!

P>>>Вы что, повсюду в бизнес-логике пишете "if user.isTest() " ? Очень вряд ли. Интеграция для тестового юзера и реального будет та же самая. Соответственно, обнаруженные проблемы практически наверняка будут играть и для тестовых юзеров.
P>·>Т.е. в конце месяца ты узнаешь, что у вас сломано создание statement? Это уже очень поздно. Ты получишь злобное письмо как минимум от каждого десятого юзера.
P>Вы снова занялись фантазированием. Вот проверили вы список проблем со значением в конфиге, условно, 5 минут.
P>А потом на проде вылезла новая проблема ровнёхонько через месяц
P>- например, задачи на создание стейтмента создаются, но висят ибо очередь забита чего у вас в тестах не было из за недостаточной загрузки
Забитость очереди, ещё раз, тривиально детектится мониторингом.

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

P>>>Мы уже выясняли — вы держите только ту часть acceptance, которую можно выполнить за полчаса. А другие на идут дальше этого 1%
P>·>Нет, мы дизайним так, чтобы любой acceptance можно было выполнить за пол часа, даже для сценариев которые требуют sleep(1 month). Время-то мочёное.
P>Значит это никакой не acceptance если вы мокаете время. Вероятно, это ваша местная специфика.
С чего это? Acceptance это не про моки, а про good to go.

P>Повторяюсь уже
P>

P>new controller(параметры)
P>

P>Отдельные части это технически вообще как юнит-тесты.
Т.е. поднимается вся инфра? Ведь контроллер может использовать ВСЁ.
Что за "параметры"? Моки, ведь, да?

P>>>Что вам непонятно было в прошлый раз? Вы продолжаете задавать один и тот же вопрос, получаете один и тот же ответ. Чего вы ждете?
P>·>Что вам непонято было в прошлый раз? Вы продолжаете гнать пургу про запуск тестов в проде случайным образом в случайные моменты времени.
P>Прогон тестов на проде это не моя придумка. Уже лет десять назад было довольно популярной практикой.
Где? Есть статьи?

P>>>Вы же сами сказали — у вас ажно 1% покрыт. Вот на остальные 99% и нужно придумать чтото получше чем есть у вас.
P>·>smoke-тестом — да, ~1%. А больше и не надо.
P>А acceptance сколько покрывает?
Почти всё. Но с моками.

P>>>Теорема Райса с вами не согласна. Нету у вас 100% надежного способа гарантировать даже true из boolean.
P>·>Верно, т.е. эти ваши тесты ничего нового не дадут.
P>мой подход сродни статической типизации — на него теорема Райса не действует


P>·>Я же объяснил, для управления этим используются другие средства вместо прогона тестов.
P>Вы эти другие пока не показали. Вам удобнее обсуждать тесты отдельно от дизайна.
Создавай новый топик, задавай вопросы.

P>>>Вашу интеграцию тестируют acceptance и smoke. я вот не удивлюсь, если окажется что ваши acсeptance это ровно то же, что и e2e
P>·>Зависит от терминологии. Acceptance работают с моками внешних систем. Это считается как e2e?
P>Условно, да
Ну ок. Т.е. мы тестируем с моками, без прода. Всё ок.

P>>>А также те, для которых тесты существуют, но причин более одной, разница прода и стейджа итд.
P>·>Разница в чём? У бинарников полное совпадение до бита. Отличаться могут только конфиги, и это контролируется diff-ом.
P>Нагрузка, данные, энвайрмент, время, сеть — отсюда и лезет недетерминизм.
Нагрузка и данные недетерминизм не создают.
Энвайрмент, время — он у вас лезет, потому что вы сами его создаёте этим же своим DateTime.Now() и бесконтрольными конфигами.
Сеть — это по сути многопоточка. Самое сложное, конечно. Но тестами оно вообще никакими не лечится, только общим подходом.

P>·>Если только недетерминизм есть какой-то, из-за ошибок в многопоточке, например. Но такое тестами и не найти, тем более на проде. Если только случайно повезёт.
P>Именно для этого некоторые конторы в момент максимальной нагрузки запускают тесты прода. Это не шутка.
P>Таким образом тестируется система в нагрузке.
Жуть.

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

P>>>Комбинаций у вас нет. Так?
P>·>Комбинации есть ровно те, что что и у вас.
P>Так и у меня их нет. И мой подход основан на пост-условиях. Это почти что статическая типизация, с некоторым упрощением.
Ага-ага Почти беременна, с некоторым упрощением.

P>А вот тесты здесь играют совсем другую роль — они фиксируют наличие пост-условия.
Не фиксируют, наивый юноша.

P>>>Структурная эквивалентность, синтаксис теореме Райса не подчиняются.
P>·>Это и означает, что ваш тест проверяет, что works as coded. Абсолютно бесполезное занятие.
P>work as coded это если копировать sql из приложения в тесты.
Так ты не стесняйся, покажи свой пример кода для которого ты показал свой тест с pattern. Получится ровно копипаст.

P>А если в приложении билдер, а в тестах — его выхлоп на конкретных параметрах, то мы напрямую проверяем маппер — о большинстве проблем вы узнаете еще до запуска на реальной базе данных
Именно, что у тебя ровно то же, что и у меня: "на конкретных параметрах". ЧТД. Статическая типизация, май год! А как дышал...

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

P>>>Ваши тесты ничего не дают без знания конкретных комбинаций на которых можно отработать тест
P>·>Ваши тоже.
P>Вы пока не смогли пример адекватный привести, который сломает хотя бы примитивный limit 10.
Привёл в ответе Sinclair с ?:-оператором.

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

P>>>В том то и дело, что не даёт. У вас нет комбинаций, а потому проверяние количества записей смысла не имеет — в тестовой базе просто нет тех самых данных.
P>·>У меня ровно те же комбинации, что будут и в твоих тестах. Отличается только часть в ассертах. Вместо проверки синтаксиса — sql-код запускается и валидируется интересный с тз бизнеса результат.
P>Комбинации в бд не показывают проблему. Следовательно, вы вытащите её на прод.
Если у меня не показывают, то и у тебя не показывают. Об чём спор-то?

P>>>В прод коде только билдер. Откуда копипаста взялась?
P>·>В прод-коде у тебя будет реализация, "LIMIT 10", в тест-коде у тебя будет .eq("...LIMIT 10").
P>.
P>Не будет. Нигде в коде приложения нет явного LIMIT 10. Лимит вычисляется билдером. Будет ли это LIMIT или подзапрос с нужным выражением — дело десятое.
P>Важно, что лимит будет обязательно. И мне не надо перебирать всю таблицу истинности билдера на интеграционных тестах.
Главное верить, и свечку поставить.

P>>>Это всё из другого проекта, я им больше не занимаюсь
P>·>Ну сделай набросок, чтобы понятно было.
P>Все что мог, я вам показал. Что еще нужно? Запрос вы видите. Он собирается из разных частей. Каждая тестируется по отдельности.
P>Главное что бы структура была корректной.
Чтобы был конкретный код, в который можно пальчиком тыкнуть. Иначе это твоё словоблудие уже надоело.

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

P>>>Известно какое — в память не влазит
P>·>Что не влазит? Кому не влазит? Нихрена не понял.
P>Результат запроса не влазит в память.
Причём тут isOdd?