Проверяет гранулярность при использовании фиктивного объекта - PullRequest
Новая
       8

Проверяет гранулярность при использовании фиктивного объекта

0 голосов
/ 15 декабря 2011

У меня есть действие Struts 1, и я хочу протестировать его отдельно. Это действие выполняется следующим образом:

  • загрузка данных с использованием параметров из запроса
  • построить представление этих данных на основе xml
  • отправить этот ответ напрямую клиенту

Я использую jMock для тестирования, но здесь есть одно сомнение. Мой первый тест - 

public void shouldActionInvocationPrintValidResponse() {
    ProcessingAction action = new ProcessingAction();

    DBService service = mock(DBService.class);
    List records = new ArrayList();
    when(service.loadData()).thenReturn(records);

    ResponseBuilder builder = mock(ResponseBuilder.class);
    when(builder.buildResponse(records)).thenReturn("fake response");

    action.execute(null, null, null, null);

    assertEquals("fake response", writer.getContentWritten());
}

И мой код продукта оценивается следующим образом: 

public String execute(...) {
    List recordsList = service.loadData();
    String response = responseBuilder.buildResponse(recordsList);
    response.getWriter().print(response);
}

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

Интересно, потому что у меня были проблемы с названием этого теста. Мои идеи в начале были чем-то вроде 

shouldFetchDataThenFormatThemAndSendResponse

Поскольку это все тесты, название показывает, что это, вероятно, слишком много (посмотрите на "и", например, в названии теста)

И должен ли я написать весь тест сразу или просто пошагово добавлять вызовы зависимостей?

EDIT: Предоставлен подробный код теста и действия.

Ответы [ 3 ]

1 голос
/ 16 декабря 2011

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

ProcessingAction action = new ProcessingAction();

Response response = action.execute();

assertEquals(true, response.IsValid);

Попробуйте: shouldGetResponseWhenActionExecuted .

Теперь вы можете посмотреть, как получить ответ при выполнении действия..

Я бы поставил вам доллары на пончики, если вы этого не делали.

Помните: Намерение превыше реализации!Хватит показывать свое хрустящее нижнее белье.

0 голосов
/ 17 декабря 2011

Я согласен с Джоном Б. Кроме того, если вы используете Mock Test Runner и пишете его правильно, вам может не потребоваться утверждение.

0 голосов
/ 15 декабря 2011

Трудно ответить на ваш вопрос, не увидев код, однако я сделаю удар.Чтобы тест был тестом Unit , он не должен использовать код, отличный от кода в тестируемом классе.Если вы издевались над каждым другим классом, который вызывает действие, и то, что вы проверяете, выполняется только внутри тестируемого класса, то нет, тест не слишком большой.Я написал модульные тесты, которые имеют большое количество операторов проверки, потому что все вещи происходят в тестируемом классе из-за одного вызова метода.

Мои правила модульного теста: 1. Код для выполнения только втестируемый класс 2. Введите тестируемый метод только один раз для каждого метода теста

...