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

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

C чего вы взяли, что я их ненавижу? Для меня моки это инструмент крайнего случая. А у вас — основной. Потому у вас почти все тесты на моках.

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

Вы каким образом это тестировать будете?

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

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

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

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

При помощи e2e можно сделать проще — всех дел, это
1 уменьшить время сессии пользователя до разумного
2 проверить что по истечении этого периода сессия завершается

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

Вот вам и ответ.

·>Не понял. Когда прогоняешь acceptance тесты, ты прогоняешь тесты для системы версии <длинный sha>. Ровно этот же sha и деплоится на прод и гарантированно имеет все те же либы и код, с точностью до бита.

Я вам про то, что вы не знаете как ведет себя ваша система. Нет способа зафиксировать каждое отдельное свойство.
У вас все равно будет разница в конфигах, разница в нагрузке, бд, сети и тд
Вот эти вещи вносят детерминизм

> Следовательно и константы имеют идентичное значение. В эпоху докер-имаджей иметь такие проблемы как у вас — должно быть просто стыдно.

Снова телепатия.

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

Ну круто — после моков бежать прокручивать вчерашние события из прода. Вот он бенефит!

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

Самосбывающееся пророчество — сначала вы так пишете код, а потом вещаете что моки это единственный вариант.

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

Наоборот.

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

Один тест будет написан немного иначе, не так как у вас. За счет упрощения огромного количества других тестов.

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

Подождем пару месяцев и выясним.

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

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

P>>Вы снова занялись фантазированием. Вот проверили вы список проблем со значением в конфиге, условно, 5 минут.
P>>А потом на проде вылезла новая проблема ровнёхонько через месяц
P>>- например, задачи на создание стейтмента создаются, но висят ибо очередь забита чего у вас в тестах не было из за недостаточной загрузки
·>Забитость очереди, ещё раз, тривиально детектится мониторингом.

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

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

Что в вашем statement такое особенное?

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

И что с того?

·>Что за "параметры"? Моки, ведь, да?

Можно и моки, если сильно хочется. Что тут такого?

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

Без понятия. Зачем вам статьи? Как вы поступили со статьей про clen architecture ?

P>>А acceptance сколько покрывает?
·>Почти всё. Но с моками.

Что конкретно вы там мокаете?

P>>Нагрузка, данные, энвайрмент, время, сеть — отсюда и лезет недетерминизм.
·>Нагрузка и данные недетерминизм не создают.

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

·>Энвайрмент, время — он у вас лезет, потому что вы сами его создаёте этим же своим DateTime.Now() и бесконтрольными конфигами.

Вы лучше расскажите, какую проблему не получится зафиксировать тестов если есть вызов now() в контроллере.
Вы который месяц говорите что это ужос-ужос, но проблему указать не торопитесь

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

Что вас тут пугает?

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

Тесты на проде запускаются не вместо тестового окружения, а после тестового окружения.
Неужели непонятно?

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

Вы что, про эйфель не слышали?

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

Расскажите, что ваши тесты делают. Посмеёмся.

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

Никакого копипаста — построение запроса это рендеринг sql по модели в json. Все что можно сказать заранее, что запрос будет select, другие не нужны.


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

OMG! Вы как раз напрямую маппер не проверяете. Этой части у вас нет. Общая часть у вас и у меня только те конкретные примеры, в которых проблемные комбинации отсутствуют.

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

Это ваша телепатия сломалась. Конкретные примеры не содержат никаких проблемных комбинаций.

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

Эта же проблема есть и у вас.

P>>Потому, что вы изначально думаете в единицах моков, и почти всё к ним и сводите.
·>Ага, да ты телепат — знаешь что я думаю. А показать-то есть что?

Мне ваши мысли не нужны — вы сами пишете, что у вас 99% тестов на моках.

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

Ну и логика

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

Буквально — мешает. Только у меня на этом держится вспомогательая вещь, а у вас — вообще всё.

P>>Результат запроса не влазит в память.
·>Причём тут isOdd?

При том, что для четности вам нужно знание о свойствах входного параметра. И тогда вы фиксируете свойство выхода.
Для правильных лимитов точно так же нужно знание о свойствах входа. И тогда вы фиксируете свойство выхода.

Но вот переборы комбинаций вам ничего из этого не дадут.