Я правильно использую издевательства?

Question

У меня есть некоторые устаревшие вещи, и я хочу покрыть это тестами.Существует следующий метод, который я не знаю, как тестировать с помощью макетов.

public String listTransactions(Request request, Response response) {
    String transactionFamily = request.get("transactionFamily");
    List transactions = service.fetchTransactions(transactionFamily);
    responseBuilder.addElement("collection", transactions);
    responseBuilder.addElement("token", tokenGenerator.next());
    String  formattedResponse = responseBuilder.build();
    response.send(formattedResponse);
    return null;
}

Мой первый подход был:

public void testResponseIsBuilt() {
    request = stub(Request.class);
    request.method("get").with("transactionFamily").willReturn("dummyFamily");
    response = mock(Response.class);
    response.mehod("send").called(once());
    service = stub(TransactionService.class);
    service.method("fetchTransactions").willReturn(testTransactions);
    responseBuilder = mock(ResponseBuilder.class);
    responseBuilder.method("addElement").called(once()).with("collection", testTransactions);
    responseBuilder.method("addElement").called(once()).with("token", sampleToken);
    responseBuilder.method("build").called(once());     
    responder.setService(service);
    responder.setResponseBuilder(responseBuilder);

    responder.listTransactions(request, response);
}

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

• testTransactionsFetchedForFamily
• testTransactionsAddedToResponse
• testTokenSetInResponse
• testFormattedResponseBuilt * 1016testResponseSent

Например, чтобы выполнить "testResponseBuilt" Мне нужно выполнить настройку следующим образом (как указано выше)

• запрос заглушки
• служба заглушки
• mock responseBuilder с 3 ожиданиями (2 addElement и 1 build)

Не слишком ли много там?Не слишком ли сложна такая настройка?Я "перегружен" здесь?

Я могу подумать о том, чтобы поместить все эти вещи responseBuilder в отдельного сотрудника, но для меня это немного сумасшествие, так как я только что извлек сам ResponseBuilder.

Я подозреваю, что упускаю некоторые важные моменты при написании юнит-тестов здесь.

Answer 1

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

Редактировать:

На второй взгляд кажется, что большая часть работы выполняется responseBuilder - оставшийся код просто устанавливаетэто до.Итак, что вы действительно можете проверить здесь, так это то, предоставлены ли ему ожидаемые данные (это один или два теста) и, наконец, отправлен ли ответ (второй / третий тест).Обратите внимание, что проверка того, вызывается ли .build, не является необходимой, так как его отсутствие может не пройти проверку отправки ответа.

Это означает, что вам нужно будет смоделировать и проверить ожидания в responseBuilder (метод .add)и response (.send).Тестовый формат ответа относится к responseBuilder test, точно так же, как проверка правильности выбора транзакций относится к service tests.

(Вы также можете проверить, что service вызывается с правильным параметром какэто жестко закодировано, но это только если вы хотите быть очень осторожными)

В целом, я бы вычеркнул тесты № 1 и № 4 и сосредоточился бы на оставшихся.

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

Answer 2

В тестовом наборе должен быть указан метод настройки, в котором должен быть указан запрос, сервис.Это обеспечит повторное использование переменных для всех ваших тестовых случаев.Чем более модульным вы сделаете, тем более точным ответом вы получите.Надеюсь, это поможет вам.