Mockowanie zewnetrznych systemów w Springboot

Cześć.
Obecnie pracuję w projekcie, gdzie nie używamy konfiguracji Springowej w xml, tylko w Adnotacjach.
w Poprzedniej pracy mieliśmy factory, które implemnetowało ContextAware, a co tym szło, mogliśmy nim "przykryć" Service (konfiguracja w xml).
Sytuacja wyglądała tak: tester mógł przełączyć zewnętrzną usługę z faktycznego systemu na mocka, przy pomocy prostego kontrolera (MVC).
W bazie danych mieliśmy zapisane flagi, co ma być włączone/wyłączone, i ewentualne wartości odpowiedzi zewnętrznego systemu.

Efekt był taki, że jak wstrzykiwałem w xml np. PaymentService, to dostawałem albo DefaultPaymentService, albo MockPaymentService -w zależności od flagi.

Pytanie, czy ktoś coś takiego z was robił w Java Config?
Albo w "czystym" Springboocie.
Pozdrawiam.

Profile Springowe (dev, test, prod)?

1. W ogóle tak nie robić. Masz w properties adres i port zewnętrznych serwisów. W testach odpalasz z testowymi propertisami plus startujesz sobie jakieś konfigurowalne serwery Http (jak np. jakis wiremock). Cała aplikacja działa tak jak powinna i używa normalnej implementacji, z tą różnicą że zamiast do prawdziwego zewnętrznego serwera, uderza do twojego httpmocka, któremu zaprogramowałeś w teście jak ma odpowiadać na konkretne query. Popatrz sobie np. na https://github.com/codewise-oss/canaveral
2. Jak już koniecznie musisz, a wątpie, to możesz to ogarnąć profilami springowymi, tzn w zalezności od profilu wystawiać takiego albo innego beana. Ale nie rób tak, bo to rakulec i takie testy guzik warte, bo nie testujesz prawdziwego kodu, tylko te swoje mockowe implementacje. Nie ma to sensu. Jak robisz unit test, to nie potrzeba takich cudów, bo tworzysz obiekty z palca, a jak robisz test integracyjny i chcesz podnieść aplikacje, to podnieś aplikacje, a nie jakiegoś fejka z połową podmienionego kodu.

Dzięki za odpowiedzi, ale to nie ja będę testował, tylko QA.
I zespół QA chce mieć możliwość przełączania na środowiskach test i stage zewnętrznych systemów np. płatności na snadbox, albo na produkcję bez restartowania środowiska.

Macie środowisko testowe wpięte do produkcyjnych płatności? :D Życzę powodzenia ;)
Ale w takim razie nie rozumiem co to ma wspólnego z twoim pytaniem postawionym w tym wątku. Bo teraz pytasz o to jak przełączyć coś w runtime, a to jest zupełnie inna sprawa niż to o co pytałeś w 1 poście.

Ok, to za bardzo się rozpisałem.
Chodzi o to jak w runtime podmienić beana.
@Shalom
Ps. Dostawczy płatności rzadko kiedy mają środowiska testowe. Na 5 integracji, które robiłem jedna ma sandbox.
w pozostałych trzeba "testować na produkcji"

Można to zrobić, ale to jest w poprzek dobrym praktykom - wdrażasz inny kod niż testowałeś. Coś macie niehalo z procesem developmentu.

"Conditional Bean" z "Custom Condition"

I np masz jakiś Singleton, który trzyma flagi i np na tej podstawie sterujesz implementacją Conditiona

Aczkolwiek

Brzmi trochę jakby problem był gdzie indziej i teraz tylko leczenie objawowe

Disclaimer: Nie ponoszę odpowiedzialności za ewentualne szkody wynikające z wdrożenia zaproponowanego rozwiązania. Co więcej, stanowczo je odradzam podobnie jak @Shalom i @danek

1. Robisz sobie komponent "dispatchera", który na podstawie wartości jakiegoś property wywołuje odpowiednią implementację/beana.
2. Podmieniasz wartość tego property w locie za pomocą Archaiusa. Za Archaiusem może stać ZooKeeper.

@Black007: Spring Boot Actuator + Spring Cloud Config + @RefreshScope + @ConditionalOnProperty wydaje się być najbardziej spring bootowym rozwiązaniem (zmiana propsów przez POST do endpointa /env).
Jednak jak poprzednicy sugerują, w kodzie produkcyjnym się tego nie robi.

Może mielibyście możliwość zdeployowania gdzieś dodatkowego proxy/mock servera, który miałby takie funkcjonalności? W takim mógłbyś mieć properties typu payments.mode=(mock|proxy) - w zależności od wartości tego property, serwis zwracałby mocka, lub forwardował do rzeczywistego endpointu.

CastleMock nie rozwiąże Twojego problemu?