@Profile тим лид запретит сделать над двумя сервисами привязанными к одному общему интерфейсу?

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

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

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

public class Bla implements EnvironmentAware
    boolean isInMock;
    @Override
    public void setEnvironment(Environment environment)  {
        var profiles = environment.getActiveProfiles();
        if (Arrays.asList(profiles).contains("mock"))
            this.isInMock = true; // маркируем бин, использует флажок в реализации для мок-ответа
    }

Но это конечно же встратый вариант. Человеческий вариант - через @Profile над бином

есть еще вариант через applicationContext доставать активные профиля.. но согласен, извращение.

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

public class Bla implements EnvironmentAware
    boolean isInMock;
    @Override
    public void setEnvironment(Environment environment)  {
        var profiles = environment.getActiveProfiles();
        if (Arrays.asList(profiles).contains("mock"))
            this.isInMock = true; // маркируем бин, использует флажок в реализации для мок-ответа
    }

Но это конечно же встратый вариант. Человеческий вариант - через @Profile над бином

А почему придется изменять? Все что обращается - будет обращаться в интерфейс с таким же именем.
Просто реальная имплементация будет либо одно, либо вторая. Имя бина-то одинаковое

public class Bla implements EnvironmentAware
    boolean isInMock;
    @Override
    public void setEnvironment(Environment environment)  {
        var profiles = environment.getActiveProfiles();
        if (Arrays.asList(profiles).contains("mock"))
            this.isInMock = true; // маркируем бин, использует флажок в реализации для мок-ответа
    }

Зачем вы каждый раз форвардите сообщение собеседника, перед тем, как ему ответить? Есть же кнопка Reply, а не Forward message.

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

на телефоне можно сообщение влево или вправо потянуть (не помню точно) - и это будет Реплай

Вообще-то изменит так как инъекция моего сервиса с помощью @Autowired в классах прописана и это как минимум и не в одном месте. Придётся тогда везде менять Бин сервиса на его интерфейс как и в классе конфиге, если чтобы бин сервиса был замокан, нужно делать мок бина из интерфейса, а не конкретного класса.

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

причем тут вообще мокито? У вас спринговый CGLIB не может запроксировать класс, который Мокито уже успешно создал. Видимо cglib не умеет проксировать созданные на лету классы. Попробуйте над своим моковым бином поставить @Scope(proxyMode = ScopedProxyMode.NO) - может быть поможет. К моку-то вряд ли вам нужны постпроцессоры всякие.

То л и я слепой, то ли текстовый файлик со стактрейсом появился после вопроса)
По стактрейсу - CGLIB. Совет выше, но возможно класс определен, как

public final class EmailService

?

Если он был final, то мокито вообще бы не смог создать ee.h2h.h2hwebserver.service.EmailService$MockitoMock$174655256

Ок. Просто мне казалось, что мок сам не был создан.

Не думал, что создание его на лету прокси может блокировать, хотя я не врубаюсь, зачем классы на лету создавать ? Ведь у меня же компиляция статическая, не JIT.

Спасибо в любом случае за советы.

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

или через AOP методы подменять)) шучу