почему просто методы не подменять АОП?Зачем мокито там?

я сначала тоже так думал, но создание своих аспектов требует в соответствующем @Aspect классе прописыванию чтото вроде advice-ов и pointcut-ов, которые как я понимаю по логике перенаправляют вызовы методов объектов определённого класса, использующийся как бин в те методы, которые написаны в этом @Aspect классе, но эти методы требуют какой-то реализации, но мокито, когда я мокаю бин в юнит тестах, он таких махинаций с аспектами в спринге не требует вообще. Заглушка ВСЕХ методов мока бина там работает и без этого

ну замокать руками пол часа/час, вы уже какой день тратите на это мокито...

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

да вам уже сказали как это делать нормально, вместо этого вы какой-то, прошу прощения, порнографией занимаетесь

хех. Вы мне советовали использовать интерфейс для мокания вместо класса. Но оказалось это не сработало. Про это вы точно говорили и всё.

вам не говорили использовать для этого мокито, вам сказали для этого создать класс, с пустыми методами

вот что я сказал.

имхо - менять класс на интерфейс, создавать бин somethingMock implements Interface и делать уже либо через @Profile, либо через @ConditionalOnProperty

Чот мне кажется что методов в бине прям очень много...

Там единая ответственность соблюдается? Мож поделить чтоб тестить удобнее было

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

легаси какое-нибудь от индусов/вьетнамцев

я помню. И я так и сделал. Просто как-то стрёмно, что в спринге стаб придётся писать самим. Без готовых либ как мокито.

да единая ответственность соблюдается. Это же глобальный сервис для отправки почты. Его разделять не нужно. Индусы и вьетнамцы тут не при чём.

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

легаси какое-нибудь от индусов/вьетнамцев

Но ок. Спасибо, что вы хоть ответили. Так что если юнит тесты не писать, мокито можно выбрасывать.

там даже в названии Employee Customer Admin везде, я бы сделал enum в качестве параметра, это в 3 раза меньше методов сразу + 3 бина за фасадом которые бы реализовывали эту логику, у них бы был 1 интерфейс, и мокать в этом случае было бы в 3 раза проще, и расширять

или просто 3 разных бина без фасада, что намного проще