Как написать модульный тест с утверждениями в рамках метода testet?

Question

У меня проблема с тем, что мне нравится тестировать некоторые значения, которые скрыты другим методом в моем тесте junit.Как бы вы к таким вещам.С мокито?Подклассы?

Здесь проблема:

public class MyService extends AbstractService {

 public ResponseObject insert(SomeData data) {
     Request request = createRequest(data);
     Response response = new Response();
     callService(request, response);
     return createResponseObject(response);
 }

 protected void callBackendService(...) {
     ...
 }
}

Как бы вы протестировали значения, переданные методу

callBackendService()

?

Есть ли более элегантный способиспользовать подклассы?

 MyService service = new MyService() {

   @Override
   protected void callBackendService(...) {
      assertEquals(...);
      ...
   }
 }

С уважением,

Майк

Answer 1

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

В противном случае, используя макетную структуру, такую ​​как Mockito, вы можете выделить метод callBackendService () в его собственный класс (например, ServiceCaller). Затем вы можете создать фиктивный объект ServiceCaller и verfiy параметры, которые ему передаются.

Как то так ...

public class ServiceCaller  {

    public callBackendService(Request request, Response response) {
        ...
    }

}

Тогда ваш класс должен выглядеть примерно так ...

public class MyService extends AbstractService {


    private ServiceCaller serviceCaller;

    public ResponseObject insert(SomeData data) {
     Request request = createRequest(data);
     Response response = new Response();
     serviceCaller.callBackendService(request, response);
     return createResponseObject(response);
    }

    public setServiceCaller(ServiceCaller caller) {
        this.serviceCaller = caller;        
    }

}

И, наконец, тест Мокито выглядит примерно так ...

@Test
public void testInsert() throws Exception {

    // object to test
    MyService ms = new MyService();

    // test input values
    Request req = new Request();

    Response resp = new Response();

    // create a mock class and inject it into your test class
    ServiceCaller sc = mock(ServiceCaller.class);

    ms.setServiceCaller = sc;

    // execute the method under test
    ms.insert(req, resp);

    // now you can see if your mock was called with the expected params
    verify(sc).callBackendService(req, resp);
}

Для краткости я опустил хороший дизайн с использованием интерфейсов и т. Д., Но вы поймете, как это сделать.

Answer 2

ПРИМЕЧАНИЕ: я предполагаю, что callService() должно быть callBackendService()

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

Кроме того, давайте посмотрим на ваш метод вставки более подробно. Если вы тестировали поведение метода createRequest() и конструктора new Response() в других тестах, вы уже знаете, что они производят именно то, что вы ожидаете. Итак, создание отдельного теста, который проверяет, что метод callBackendService() получил параметры, которые вы ожидаете в этом случае, действительно не проверяет ничего нового.

Что вам нужно сделать, это проверить результат вызова метода insert().

Итак, ответ на ваш вопрос: не проверяйте аргументы метода callBackendService().

Answer 3

Не проверяйте callBackendService (), если это просто деталь реализации.Если он настолько сложен, что заслуживает своего собственного тестирования, реорганизуйте его в отдельный класс.