Почему я должен использовать MockRunner для нормальной/ручной прокатки зависимости?

Question

В нашей comapny у нас есть сервисный уровень, который принимает некоторый запрос XML, обращается к различным хранимым Procecdures (SP) через JDBC, обрабатывает данные и отвечает на некоторые ответы XML. В последнее время люди начали принимать MockRunner в своих тестах JUnit, чтобы издеваться над ответами SP. Код для установки на издевались отклики с помощью MockRunner СП выглядит ужасно (это первый случайный тест класс я открыл):

MockConnection connection = new MockConnection(); 
    MockContextFactory.setAsInitial(); 
    InitialContext context = new InitialContext(); 
    context.rebind(READ_PAYMENT_DATA_SOURCE, getDS()); 
    getDS().setupConnection(connection); 
    m_csStatementHandler = connection.getCallableStatementResultSetHandler(); 
    m_csStatementHandler.clearResultSets(); 
    m_csStatementHandler.clearCallableStatements(); 
    m_csStatementHandler.setExactMatch(false); 
m_csStatementHandler.prepareReturnsResultSet(READ_PAYMENT, true); 
    m_csStatementHandler.setExactMatch(false); 
    m_csStatementHandler.setExactMatchParameter(false); 
    Map parameterMap = new HashMap(); 
    parameterMap.put(new Integer(1), null); 
    parameterMap.put(new Integer(2), null); 
    parameterMap.put(new Integer(3), null); 
    parameterMap.put(new Integer(4), null); 
    m_csStatementHandler.prepareOutParameter(READ_PAYMENT, parameterMap); 
    //Set up the cursor of applications for return. 
    MockResultSet resultApps = m_csStatementHandler.createResultSet(); 

    resultApps.addRow(getPaymentSchedule("E", "Monthly", new Short("1"),null,null,null,null,null,null,null)); 
    resultApps.addRow(getPaymentSchedule("A", "Weekly", new Short("1"),null,null,null,null,null,null,null)); 
    resultApps.addRow(getPaymentSchedule("R", "Yearly", new Short("1"),null,null,null,null,null,null,null)); 
    resultApps.addRow(getPaymentSchedule("S", "Weekly", new Short("1"),null,null,null,null,null,null,null)); 
    resultApps.addRow(getPaymentSchedule("W", "Monthly", new Short("1"),null,null,null,null,null,null,null)); 

    MockResultSet[] results = new MockResultSet[1]; 
    results[0] = resultApps; 
    m_csStatementHandler.prepareResultSet(READ_PAYMENT, resultApps); 

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

На данный момент я использовал инъекцию зависимостей вручную, чтобы ввести класс, который фактически вызывает хранимую процедуру. Все, что мне нужно сделать, это создать класс вызова вызывающего модуля SP (отвечающий за фактическое выполнение SP) и установить мои требуемые данные ответа. Я очень доволен этой техникой и ее намного проще, чем выше, поскольку ее данные сосредоточены, а не беспокоятся о деталях реализации. Но мой вопрос: когда вы хотите использовать MockRunner? Кажется, излишним для модульных тестов, так что я предполагаю, что он больше подходит для интеграции или тестирования системы? И даже тогда мне по-прежнему проще использовать фреймворк DI для замены класса вызывающего SP, а затем настроить весь код выше для каждого вызова хранимой процедуры. Пожалуйста, просветите! Спасибо

Answer 1

В конечном счете вы изучаете философию, издевательствовающую в целом. Я дам вам свои два цента, но я бы также упомянул вас о какой-либо крупной насмешливой библиотеке, которая, вероятно, будет служить хорошим оправданием для их собственного существования. Например, возьмите Mockito.

Сообщество, тестирующее/издевательское сообщество, часто отличает то, что вы делаете вручную, что обычно называется «заглушкой» (статическим, написанным вручную классом) по сравнению с «макетом» (динамическим,).

Преимущества издевательств довольно велики по сравнению с просто ступицей. Многие тестировщики раздражают идею перехода к реализации интерфейсов и/или подкласса конкретных классов только для целей тестирования. Для этого часто требуется реализация ВСЕХ методов указанного класса/интерфейса, даже если вы просто хотите протестировать определенный метод.

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

Синтаксис немного отличается от насмешливой библиотеки библиотеки. Некоторые из них могут быть более читаемыми, чем другие. Моим нынешним фаворитом является Mockito, следовательно, более ранняя ссылка, но они меняются со временем. Возможно, стоит определить, почему ваша организация использует насмешливый пакет, и что еще может удовлетворить ваши потребности, а также быть более читабельными.

Надеюсь, ваши авторы-испытатели вытаскивают общее поведение в методы тестирования (например, JUnit's @Before), поэтому вам не нужно постоянно следить за макет-созданием и общей инициализацией.