Мне кажется, что в этом примере, сага будет некоторым перебором. Здесь, как мне кажется, вполне хватит обычного transactional outbox, если мы можем гарантировать идемпотентность по сообщениями на стороне системы получателя.
В сторону от темы: Вы же понимаете, что все эти требования, про то, что юнит-тест должен, а чего не должен, не обоснованы ничем (я, естественно, читал все эти теоретические обоснования, и говорю это на основе прочитанного), кто-то верит, что оно должно быть так, как в википедии написано, кто-то нет. Это не особо важно - разработка это ремесло, а не теория. Есть распространённые примеры других подходов, например в Рельсах тесты на реальной БД идут из коробки, и называются юнит-тестами (работает в точности по описанной выше схеме).
По теме: Мы говорим не об абстрактном коде, а именно о коде взаимодействующем с базой данных. Этот код почти всегда включает запросы к БД (ORM тоже, просто вы их не видите). Т.е. у нас есть, как-бы isolated source code, который включает инструкции к внешней системе, которые только эта внешняя система и может интерпретировать. Это точно isolated? Печальный факт состоит в том, что на моках базы данных вы никак не проверите, что внутри этих запросов написано (нестрого говоря, тесты репозитория на моках - это погружение в мир иллюзий, у вас как-бы 100% покрытие, но при этом всё равно deploy-and-pray стиль интеграции). И если раньше (давно) тестирования кода на реальной базе данных было сопряжено с некоторыми техническим трудностями, то сейчас контейнеризация решила большую часть этих проблем. Технически, у вас всё равно есть какой-то setup метод, который выполняется до тестов, и большая ли разница, общие моки там настраиваются, или контейнер в память поднимается.
Тут, конечно, может быть терминологический вопрос, он же вопрос про скоуп интеграционного теста. В нашей практике, интеграционный тест - это тест который который поднимет все микросервисы, участвующие в каком-то воркфлоу. Юнит-тест, понятно, изолированный кусок кода на моках. Но между этими вариантами есть целый спектр других уровней автоматизированных тестов, и где там ставить границу интеграционного теста это, по большому счёту, вопрос соглашения.
И по основному тезису - если у вас есть тесты на реальной БД (называйте их как угодно), то тестирование хранимок ничем не отличается от тестирования запросов. Если таких тестов у вас нет... ну, не знаю, наверное есть отрасли где данные ничего не стоят, сам не видел, врать не буду.
Насчёт тестирования. Автор наверное забыл упомянуть про возможность тестов на реальной СУБД? Я не то, чтобы фанат хранимок, но надо как-то реальные недостатки обсуждать, а не проблемы возникающие от незнания/неумения.
Проблемы, описанные в разделах "Сложность в тестировании" и "Автоматическое тестирование или unit-тесты" в значительно мере могут решены связкой test-containers + [ваш любимый инструмент миграции] (для распространённых СУБД всю конструкцию можно запустить за день с нуля). В этом случае, интеграционный тест на хранимку собственно и будет её актуальной документацией.
А жизнь в собственном информационном пузыре приводит к вот таким комментариям. Потому как за пределами вашего пузыря, кроме алгоритмов, которые выполняет компьютер, существуют алгоритмы, которые выполняют люди и, иногда, целые организации. И тут проблемы визуализации и стандартизации алгоритмов встают во весь рост. Дракон, как мне кажется, стоит рассматривать не как графический язык программирования, а как что-то в ряду блок-схем ГОСТ-а, IDEF3, BPMN и т.п.
Если позволите, ещё один вопрос, на тему собственно автоматизации. Вернее, на тему соотношения бонусов и рисков автоматизации. Я конечно понимаю, что именно в этом го-го всё абсолютно законно, у всех девушек Non-B визы, на каждую нанято по четыре тайца, а арабы приходят в это го-го исключительно для того, чтобы насладиться искусством танца.
Но давайте представим некоторое другое го-го на Волкинге, не имеющее отношения к Вашему другу, которое работает как обычно и как все. В существующей системе, тетрадочка с чеками может вообще в руки полиции не попасть. Может потеряться, может промокнуть по дороге в участок (дожди, знаете ли). Да даже если она и попадёт в полицию в первозданном виде — надо ещё доказать, что строчкам в тетрадке соответствуют именно те девушки, которые сейчас сидят в кузове пикапа иммиграционной службы. А в новой автоматизированной системе — база данных, которую правильные ИТ-шники не забудут регулярно бэкапить, на телефонах у девушек — приложение для работы с этой базой. Доказательная база — вся и сразу.
Не получится ли так, что вместе с не очевидными бонусами внедрения, владелец этой системы получит вполне очевидные риски?
Ну и строго говоря — их работа в го-го на Волкинге, с точки зрения закона, тоже возможна исключительно благодаря зашкаливающему уровню коррупции в полиции города Паттайя
А, так это го-го с европейскими девушками… Тогда прошу прощения, мои комменты можно стирать. Я просто попытался представить себе тайскую бар-гёрл, которая потеряла чеки за свои леди дринки, и честно говоря, не смог.
Ага. Именно так — работала бесплатно. После чего осознала, что не вполне пригодна к такого рода работе, устроилась кассиром в 7/11, свернула с кривой дорожки, вышла замуж, завела детей, стала уважаемым членом общества. Ходит в храм по праздниками и благодарит Будду за тот день, когда потеряла эти чеки. От заведения не убудет, желающих много.
А почему ваш друг не использовал традиционную для тайских баров схему? На столе в стаканчике всегда один чек — он же счёт для оплаты гостями (Если компания будет считаться по отдельности, то один чек на гостя). Сценарий работы такой — клиент заказывает дринк себе и леди-дринк для бар-гёрл. Бар-гёрл идет к кассиру, и получает два чека — обновленённый счёт для клиента, который она уносит клиенту, и чек за леди-дринк, который она осталяет себе. В конце смены, деушки подходят к кассиру со свомим чеками и получают комиссию. Прблема может быть одна — бар-гёрлз в кабаках обычно гораздо более одеты, чем девушки в го-го, поэтому нет проблемы с тем, куда положить чек. С другой стороны в го-го они всё равно с собой телефоны таскают, обычно в чехлах. Могут купить себе чехол с карманчиком.
какой именно возможности нет?
https://www.keycloak.org/docs/latest/server_development
Мне кажется, что в этом примере, сага будет некоторым перебором. Здесь, как мне кажется, вполне хватит обычного transactional outbox, если мы можем гарантировать идемпотентность по сообщениями на стороне системы получателя.
[о да, религиозные фанатики в интернете...]
В сторону от темы: Вы же понимаете, что все эти требования, про то, что юнит-тест должен, а чего не должен, не обоснованы ничем (я, естественно, читал все эти теоретические обоснования, и говорю это на основе прочитанного), кто-то верит, что оно должно быть так, как в википедии написано, кто-то нет. Это не особо важно - разработка это ремесло, а не теория. Есть распространённые примеры других подходов, например в Рельсах тесты на реальной БД идут из коробки, и называются юнит-тестами (работает в точности по описанной выше схеме).
По теме: Мы говорим не об абстрактном коде, а именно о коде взаимодействующем с базой данных. Этот код почти всегда включает запросы к БД (ORM тоже, просто вы их не видите). Т.е. у нас есть, как-бы isolated source code, который включает инструкции к внешней системе, которые только эта внешняя система и может интерпретировать. Это точно isolated? Печальный факт состоит в том, что на моках базы данных вы никак не проверите, что внутри этих запросов написано (нестрого говоря, тесты репозитория на моках - это погружение в мир иллюзий, у вас как-бы 100% покрытие, но при этом всё равно deploy-and-pray стиль интеграции). И если раньше (давно) тестирования кода на реальной базе данных было сопряжено с некоторыми техническим трудностями, то сейчас контейнеризация решила большую часть этих проблем. Технически, у вас всё равно есть какой-то setup метод, который выполняется до тестов, и большая ли разница, общие моки там настраиваются, или контейнер в память поднимается.
Тут, конечно, может быть терминологический вопрос, он же вопрос про скоуп интеграционного теста. В нашей практике, интеграционный тест - это тест который который поднимет все микросервисы, участвующие в каком-то воркфлоу. Юнит-тест, понятно, изолированный кусок кода на моках. Но между этими вариантами есть целый спектр других уровней автоматизированных тестов, и где там ставить границу интеграционного теста это, по большому счёту, вопрос соглашения.
И по основному тезису - если у вас есть тесты на реальной БД (называйте их как угодно), то тестирование хранимок ничем не отличается от тестирования запросов. Если таких тестов у вас нет... ну, не знаю, наверное есть отрасли где данные ничего не стоят, сам не видел, врать не буду.
Насчёт тестирования. Автор наверное забыл упомянуть про возможность тестов на реальной СУБД? Я не то, чтобы фанат хранимок, но надо как-то реальные недостатки обсуждать, а не проблемы возникающие от незнания/неумения.
Проблемы, описанные в разделах "Сложность в тестировании" и "Автоматическое тестирование или unit-тесты" в значительно мере могут решены связкой test-containers + [ваш любимый инструмент миграции] (для распространённых СУБД всю конструкцию можно запустить за день с нуля). В этом случае, интеграционный тест на хранимку собственно и будет её актуальной документацией.
Но давайте представим некоторое другое го-го на Волкинге, не имеющее отношения к Вашему другу, которое работает как обычно и как все. В существующей системе, тетрадочка с чеками может вообще в руки полиции не попасть. Может потеряться, может промокнуть по дороге в участок (дожди, знаете ли). Да даже если она и попадёт в полицию в первозданном виде — надо ещё доказать, что строчкам в тетрадке соответствуют именно те девушки, которые сейчас сидят в кузове пикапа иммиграционной службы. А в новой автоматизированной системе — база данных, которую правильные ИТ-шники не забудут регулярно бэкапить, на телефонах у девушек — приложение для работы с этой базой. Доказательная база — вся и сразу.
Не получится ли так, что вместе с не очевидными бонусами внедрения, владелец этой системы получит вполне очевидные риски?