Стратегия для Spring, Feign и TestNG

В настоящее время у меня есть проект, использующий TestNG для выполнения тестов моего проекта Spring. В моем проекте у меня есть набор интерфейсов Feign, которые обрабатывают внешние вызовы в моей конфигурации Eureka. Мне трудно понять, как имитировать/перехватывать эти вызовы для каждого теста во время выполнения.

Вот пример одного из моих интерфейсов Feign:

@FeignClient ("http://my-service")
public interface MyServiceFeign {

    @RequestMapping (value = "/endpoint/{key}", method = RequestMethod.GET)
    SomePojo getByKey(@PathVariable ("key") String key);
}

У меня есть служба, которая зависит от клиента:

@Service
public class MyService {

    @Autowired
    private MyServiceFeign theFeign;

    public SomePojo doStuff() {
      return theFeign.getByKey("SomeKey");
    }
}

Мои тесты запускаются просто через:

@SpringBootTest (
    classes = Service.class,
    webEnvironment= SpringBootTest.WebEnvironment.RANDOM_PORT
)
@TestExecutionListeners (
    inheritListeners = false,
    listeners = {
        DependencyInjectionTestExecutionListener.class,
        TransactionalTestExecutionListener.class
    }
)
@DirtiesContext
@ContextConfiguration (initializers = CustomYamlLoader.class)
@ActiveProfiles ("test")
publi class MyModuleTest extends AbstractTestNGSpringContextTests {
    // ....
}

Что я хочу сделать в своем тесте, так это выполнить что-то вроде этого:

@Test
public void doSomeTest() {
   SomePojo fakeReturn = new SomePojo();
   fakeReturn.setSomeStuff("some stuff");

   /*
     !!! do something with the injected feign for this test !!!
     setupFeignReturn(feignIntercept, fakeReturn);
   */

   SomePojo somePojo = injectedService.doStuff();
   Assert.assertNotNull(somePojo, "How did I get NULL in a fake test?");
}

Итак, вот моя дилемма: мне не хватает ключевого понимания, чтобы сделать это, я думаю. Это или я полностью отсутствует концепция того, как это должно быть обработано. Я не думаю, что здесь имеет смысл использовать резервную реализацию, но я могу ошибаться.

Помощь!


java spring testng spring-cloud-feign netflix-feign
person el n00b    schedule 17.02.2017    source источник
comment
Например. Мокито. Вы когда-нибудь слышали?   -  person Grzegorz Górkiewicz    schedule 17.02.2017
comment
Я думаю, я должен быть более ясным - позвольте мне обновить описание.   -  person el n00b    schedule 17.02.2017
comment
Я не минусовщик. Я проголосовал за баланс. Я думаю, вы ищете насмешки.   -  person Grzegorz Górkiewicz    schedule 17.02.2017
comment
Я переключился на настройку этого с помощью сервиса. Я не собирался насмехаться после прочтения этого: for unittesting">stackoverflow.com/questions/34397570/ -- я понимаю, о чем они говорят, и чувствую, что должен каким-то образом перехватить вызов без насмешек.   -  person el n00b    schedule 17.02.2017

Ответы (1)


arrow_upward
1
arrow_downward

насколько я понимаю, вы имеете дело с фиктивными клиентами (и, возможно, с безопасностью наверху, например, с базовой аутентификацией или OAuth2) и хотите провести тесты. Но на самом деле это не проверка того, что MyServiceFeign работает, а MyService работает правильно, учитывая, что ложный клиент получает действительный результат.

Для этой цели вы на самом деле не внедряете своего фиктивного клиента, вы издеваетесь над ним.

Короче говоря, этого можно достичь двумя шагами: используя @MockBean вместо @Autowired и описывая поведение ваших клиентов, прежде чем использовать его.

@RunWith(SpringRunner.class)
@SpringBootTest(classes = YourApp.class)
public class MyServiceUnitTest {

    @MockBean
    private MyServiceFeign myFeignClient;

    @Autowiered
    private MyService myService;

    @Test
    public void testSync() {
        given(myFeignClient.getByKey("SomeKey")).willReturn(
            new SomePojo("SomeKey")
        );
        assertEquals("SomeKey", myService.doStuff().getKey());
    }
}

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

person David Steiman    schedule 27.02.2017