уже слишком сложно. надо уже какой то NLP чтобы адекватно было

банально по справочнику уже не плохо

обходится на раз два старыми дедовскими х.у.й. и прочее)))

главное что бы не было как с allopenissues

я знаю

Да че там сложного. Я вижу это как есть набор слов (шаблонов), которые вводит сам пользователь (это может быть не админ и не только маты), и мы берем каждое сообщение и проверяем на наличие шаблона в тексте. Допустим в pro.jvm jobs мне интересно, когда вакансия на джуна выскочит, я в базу добавляю "junior", "джуниор" и т.п. и мне уведомление прилетает, когда такая вакансия появится. Или к примеру в этом чате меня интересуют посты со словом скажем "context", так как я его изучаю например или есть знания, которыми по этой теме могу поделиться.

Да и сборки шаблонов по темам тоже можно добавить.

понятно. неплохая идея, согласен)

Если будут еще желающие тему поразвивать, то я в теме) Осталось апи телеграмма изучить=)

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

я вроде такое профайлами делал.

объявлял этот бин только в каком-то одном профайле, затем в дефолтном конфиге этот профайл инклудил (spring.profiles.include=...), т.е. даже если его явно не задать, он все равно активен по дефолту. А в тестовом конфиге не инклудил.

вроде так, если правильно вспомнил.

Еще есть такой параметр: spring.main.allow-bean-definition-overriding=true

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

А через @Primary бин не?
Заменить на Noop.

как вариант, да

@MockBean объявляешь и он будет подтягиваться

public @interface MockBean
Annotation that can be used to add mocks to a Spring ApplicationContext. Can be used as a class level annotation or on fields in either @Configuration classes, or test classes that are @RunWith the SpringRunner.
Mocks can be registered by type or by bean name. Any existing single bean of the same type defined in the context will be replaced by the mock. If no existing bean is defined a new one will be added. Dependencies that are known to the application context but are not beans (such as those registered directly) will not be found and a mocked bean will be added to the context alongside the existing dependency.

When @MockBean is used on a field, as well as being registered in the application context, the mock will also be injected into the field. Typical usage might be:

вообще зависит от того что надо, если везде подменять то лучше конфигурацией/профилями, если конкретный тест то аннотацией

Конкретный интеграционный тест. Просто наполняю базу, дёргаю методы контроллера и ожидаю на выход сохраненные данные, образно говоря. А компонент, который хочу отключить, при отсутствии данных в базе лезет за данными налево и сохраняет данные в базу, и делает это на этапе ApplicationContextReady.

ну тогда эта аннотация должна идеально решать вашу проблему

@MockBean
бинКОторыйНеХодитПоВнешнимАпиИНичегоНеЛомает

Если в тесте замокаю этот Бин и не буду его использовать, то он в сеть за данными не полезет?