https://gist.github.com/nemanovich/922f2b198d08bc602afe119baa2b33ef пример, как может выглядеть сборка запускаемого jar со всеми зависимостями. Способ естественно не единственный

Проходите вот этот курс и на выходе у вас готовый шаблон проекта: https://stepik.org/course/575/syllabus

Всем привет.
Интересует такой вопрос. Можно как то засунуть в postman у запросе файл или img по ссилке ?

Можно через form-data

Антифрод работает на основе правил. Т.е. транзакция должна подходить под какое-то правило (серое или черное) и по ней начисляются баллы скоринга. Система скорига настраивается отдельно. Например, >=300 попадают тел. или карты, которые есть в справочниках black листа.

Спасибо))

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

Всяко такие штуки лучше юнит-тестами покрывать.

Многие кейсы вообще невозможно покрыть без моков и хаков. Ну вот как ты сгенерируешь две транзакции в одну и ту же миллисекунду с двух разных айпишников? Или наоборот, две транзакции с разницей в 23:59

время синхронизировать. работать с картой в обход стека ядра. но это оверкилл.)

Один из вариантов контроля регрессии - использовать подготовленные сеты данных. Условно говоря, прогнали старую и новую версию на одних и тех же данных - получили более-менее одинаковые результаты. Тестировать такие вещи как антифрод детерминированно довольно тяжело, потому что тут сервис идет в плотном комплекте с бизнес-правилами. Условно говоря, завтра аналитик добавит десять новых правил и удалит пять старых, и все старые тесты в помойку. Тестировать же сервис отдельно от бизнес правил можно (и нужно!), но опять же надо понимать, что без настроек скоринга само приложение ценности не имеет, так что это чисто компонентные тесты.

Скоринг это другое. Там вроде просто правило. Это требования для предусловий, дальше делаете операции по спец картам или по спец категориям на определенные суммы в определенное время( ночью например) Правила уже есть в самой системе, надо чтобы они тригернулись

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

Так вот именно - если изменили 15 правил, то на одном и том же датасете получатся совершенно разные результаты. И как определить, корректно ли изменились правила и не затронули ли изменения то, что затрагивать было не нужно?
Это же не машинное обучение, где всё работает вокруг вероятности и качество модели оценивается вероятностью, а вполне детерминированные правила. И можно создать фреймворк, в котором эти правила будут описываться простой нотацией типа ямла и не нужно будет тратить большое время на поддержку тестов

По идее, должны быть отдельные тесты, на каждое правило

Логика такая, что 99 процентов должно остаться тем же, остальное проанализировать. Т.е это не замена функциональному тестированию фичи, это попытка избежать ситуации "выкатили фичу, половина транзакций отвалилась". Расчет на то, что каждое изменение не сильно меняет общую картину, при этом каждый новый кейс будет рассмотрен вручную. По идее надо бы писать тест под каждое правило, но тут уже вопрос про разделение зон ответственности между разработкой и бизнесом.

Не обязательно. Есть правила, где срабатывает триггер, а есть, где считается скоринг. Так, например, транзакция, проходя через серые правила, может набрать баллы и карта попадёт в подозрительные.

Кто читал xUnit Test Patterns: Refactoring Test Code, Gerard Meszaros?
https://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054https://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054

Насколько она полезна тестировщику?

полезна

неплохая кстати книжка