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


P>·>Так "да" или "нет"?
Т.е. прямой вопрос ты опять игнорируешь и продолжаешь лить воду.

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

>> Суть в том, что даже в таком тривиальном примере мок есть и это факт, а факт вещь упрямая.
P>Что раз Фаулер так делает, то иначе ну никак нельзя?
Нельзя. И ты ещё не показал, что можно. Код у тебя весь есть, сделай форк и вперёд, а я [willy-wonka-meme.gif].

P>Моки можно всунуть куда угодно, хоть для теста синусов и косинусов, — это ничего не говорит.
Ты говорил, что моки и это всё — это старьё из 00х. Как оказалось — и тут ты налажал, т.к. статья 2023 года имеет те же самые "устаревшие" моки.

P>>>То есть, вы снова предлагаете бороться с data complexity посредством большого количества тестов на реальной бд.
P>·>Нет, такое я не предгалаю.
P>Именно это вы и говорите. Ну, как вариант, не читаете.
Ты нафантазировал "на реальной бд", а я писал "на бд близкой к боевой (только не по количеству записей, а по качеству)". Разницу не видишь, да?

P>И вы предлагаете вместо этих тестов гонять всё через бд. Откуда ясно, что 1 время прогона увеличивается на порядки, 2 боевых данных у вас нет — пойдете к менедеджеру "Вася, я тесты в следуюем году подкину"
Это опять твои фантазии из неумения читать, что тебе пишут.

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

P>·>Есть, конечно. Например, изменяется транзакционность, согласованность, &c. Ты это даже не понимаешь, что это именно функциональность.
P> Согласованность, транзакционность, задержка — это всё НЕФУНКЦИОНАЛЬНЫЕ.
Как это? Возможность поизменять пользователя после его создания — это функциональное требование.

P>Т.е., условно, вы выяснили, что не успеваете, опаньки! И надо выталкивать процессинг в очередь. Упс — написали тесты, покрыли моками, выбросили моки, переписали тесты, но уже на других моках, ой...
Это требует согласования с бизнесом, а не просто так, чтобы не было тех чудес как у тебя бывает.

P>·>Да у тебя всё разновидность интеграционных. Конформационные тесты подразумевают, что внешний сервис тестируется отдельно от проекта. И проект отдельно тестируется с моками внешнего сервиса. Что с чем тут интегриуется — я не могу представить, моя фантазия не настолько безграничная.
P>Интеграция начинается с момента, когда одна ваша функция вызывает другую вашу функцию. Конформационный тест требует запуска приложения или подсистемы, что автоматически означает интеграционный уровень.
Нет, конформационный тест не требует запуска приложения или системы. Читай мою переписку с Sinclair.

P>Правильно понимаю, вы собираетесь тестировать эскейпинг каких кавычек, собирая приложение и запуская его против мока внешнего сервиса?
Нет, не правильно понимаешь.

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

P>>>Например, мы можем проверить, что делаем правильный энкодинг, правильную склейку, правильный маппинг, правильный эскейпинг, итд и тд.
P>·>Не можете. Такими тестами вы можете проверить, что текст запроса равен select *...., но не можете проверить, что он правильный. Правильность текста запроса будут проверять только ваши юзеры в проде, т.к. и интеграционными тестами не можете покрыть каждый запрос, ибо data complexity для тестов проекта в сборе выше, чем в тестах реп.
P>В который раз объясняю. Нам нужны 2 условия(ДВА!)
P>1. рабочий паттерн запроса — это проверяется сначала руками, а потом тестом против бд минимально заполненой под задачу
P>2. рабочая схема построения такого паттерна
P>1 — необходимое условие
P>1 + 2 необходимое и достаточное
Я не знаю что ты в этом месте понимаешь под "паттерн", но я всегда имел в виду твой конкретный "const pattern =" вот тут

Автор: Pauel
Дата: 28.12.23

. Такой паттерн вручную прповерять — большая беда, надо тестировать с бд автоматически.

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

P>- маппер параметр->значение это целая куча кейсов, много больше, чем вы можете себе позволить методом "гонять на бд близкой к боевой"
Но эти кейсы плотно связаны с тем как выглядит реальный recordset. Например, о том как субд превращает null в default value я тебе уже рассказал. И в твоём подходе это остаётся непокрытым.

P>>>Подробнее — как вам моки помогут гарантировать, что всё многообразие символов вы энкодите согласно протоколу?
P>·>"согласно протоколу" — это и есть конформационные тесты, по определению. Моки же позволяют не маяться дурью гарантирования энкодинга в тестах вашей бизнес-логики.
P>Вы реализацию хоть какого клиентского протокола видели когда нибудь? Там сотни и тысячи тестов покрывают кейсы вида '$var- заменяем на значение var с удалением всех пробельных символов после нее'
P>Фильтр который вы пишете, это ровно такой же специализированый клиент. И тут, о чудо, можно обходиться без всех таких кейсов
Это будет код и тесты клиента для протокола, а не код бизнес-логики твеого приложения, которое этого клиента использует.

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

P>·>И? Предлагаешь это не тестировать вообще?
P>Я уже третий месяц рассказываю как именно это нужно тестировать.
Меня ответы "никак", "руками", "используя реальные данные за 2025 год" не устраивают. А с другими ответами ты не соглашаешься.

>>По факту ты просто загоняешь свои assumptions что надо "так, а не эдак" в свой pattern и оставляешь это вообще не покрытым вообще никак.
P>Работает ли паттерн корретно, и строится ли он корректно — это два множества вариантов которые всего лишь пересекаются.
Почему пересекаются? Каким образом некорректно построенный паттерн может работать корректно? Раз работает, значит построен.
Разница значительна: "Работает ли" — важно и нужно тестировать, инвариант диктуемый бизнесом, "строится ли" — это мелкие детали имплементации, которые меняются постоянно.

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

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

P>Интеграционные тесты проверяют его еще раз, на бд.
В на прод-бд с данными за 2025 год. Я правильно понял?

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