2008-10-23 7 views
0

Я новичок в jmock и пытаюсь высмеять HttpSession. Я получаю:Как работает Jmock с HttpSession и HttpServletRequest

java.lang.AssertionError: неожиданный вызов: httpServletRequest.getSession() никаких ожиданий указания: вы ... - забудьте начать ожидание с пунктом мощности? - вызов метода издевательства, чтобы указать параметр ожидания?

метод испытания:

@Test

public void testDoAuthorization(){ 

    final HttpServletRequest request = context.mock(HttpServletRequest.class); 
    final HttpSession session = request.getSession(); 

    context.checking(new Expectations(){{ 
     one(request).getSession(true); will(returnValue(session)); 
    }}); 

    assertTrue(dwnLoadCel.doAuthorization(session)); 
} 

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

ответ

2

Вам не нужно издеваться над объектом запроса. Поскольку метод, который вы тестируете (dwnLoadCel.doAuthorization()), зависит только от объекта HttpSession, вот что вы должны издеваться. Так что ваш код будет выглядеть следующим образом:

public void testDoAuthorization(){ 
    final HttpSession session = context.mock(HttpSession.class); 

    context.checking(new Expectations(){{ 
     // ??? 
    }}); 

    assertTrue(dwnLoadCel.doAuthorization(session)); 

}

Возникает вопрос: что вы ожидаете, что SUT на самом деле сделать с объектом сеанса? Вы должны выразить в своих ожиданиях призывы к session и их соответствующие возвращаемые значения, которые должны привести к doAuthorization, возвращающему true.

1

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

final HttpServletRequest request = context.mock(HttpServletRequest.class); 

context.checking(new Expectations(){{ 
    one(request).getSession(true); will(returnValue(session)); 
}}); 

final HttpSession session = request.getSession(); 

Я не супер знакомы с JMock, но вы на самом деле все равно в тестовом модуле dwnLoadCel сколько раз определенные методы в издевался объекта называются? Или вы просто пытаетесь проверить свой класс, который зависит от HttpSession без фактического сеанса? Если это последнее, я думаю, что JMock слишком много для вас.

Вы можете посмотреть в любое создании класса, который реализует HttpSession интерфейс самостоятельно для целей модульного тестирования только (заглушки) и запуск ваших тестов от этого, или вы должны взглянуть на dwnLoadCel и определить если он действительно должен иметь ссылку на HttpSession, или ему нужны только некоторые свойства внутри HttpSession. Refactor dwnLoadCel зависит только от того, что ему действительно нужно (Map или определенного значения параметра в объекте Session) - это упростит ваш модульный тест (зависимость от контейнера сервлета идет пока).

Я думаю, что у вас уже есть некоторый уровень инъекции зависимостей в вашем классе, который уже протестирован, но вы можете быть зависимы от слишком широкого объекта. The Google Test Blog имеет a lotof excellentarticles на DI в последнее время, что вы можете найти полезным (я уверен, что есть).

+0

хорошо ответ. После рассмотрения проблемы кажется разумным взглянуть на класс, который dwnLoadCel использует для doAuthorization. Возможно, рефакторинг - это вариант. – SWD 2008-10-25 15:41:36

+0

Для записи есть предложение allow() в jMock, которое эффективно блокирует вызов. Это позволяет делать вызов столько раз, сколько вам нравится.Обычно мы «разрешаем» запросы, которые не меняют состояние соавтора – 2010-01-22 13:04:54

Смежные вопросы