2013-05-31 5 views
0

Я пытаюсь написать модульный тест для некоторых вызовов процедуры jdbc с помощью mockito. Это мой первый раз, когда я пишу тесты с макетными объектами (mockito).Вызов процедуры Mockito и jdbc

Метод я пытаюсь тест выглядит некоторые вещи, как это ...

public void deleteData(final Connection connection, final AnObject) { 
    CallableStatement statement = null; 

    statement = connection.prepareCall("{call DEL_DATA(?)}"); 
    statement.setInt(1, object.getId()); 

    statement.executeUpdate(); 

    connection.commit(); 

    DatabaseSql.close(statement); 
} 

Как я могу проверить методы, как это с Mockito и JUnit?

Заранее спасибо.

+1

Что вы хотите проверить? Потому что я ничего не могу проверить в этом коде. – fiso

ответ

4

Нет смысла писать единичный тест для этого кода. Как только вы издеваетесь над частями доступа к БД, для модульного теста логики не осталось.

Вам необходимо высмеять вашу бизнес-логику без вашего кода настойчивости.

+0

Спасибо за быстрый ответ :) Я действительно не уверен, если я должен его протестировать. Вы имеете в виду, что нет необходимости или способ проверить код? – user2439522

+0

Нет смысла в «блоке» тестировать вышеуказанный код. Но, конечно, вы можете протестировать код. Но тогда это будут интеграционные тесты, в которых будут обсуждаться и проверять данные, которые записываются в db. Подумайте об этом, если вы издеваетесь над частью db кода, есть логика, которую вы можете проверить. –

0

Ну, короткий ответ: «вы не можете, это не то, для чего оно предназначено».

Кроме того, ваш метод "deleteData" не подвергается прямому тестированию и имеет недопустимую подпись.

Чтобы проверить работоспособность вашей функции, вам необходимо сначала вызвать ваш метод deleteData, а затем попытаться загрузить удаленные данные (при условии, что ваш DataStore является ACID) и утверждать, что загруженные данные не существуют. Это не единичный тест (потому что он не изолирован).

Либо перепишите свою персистенцию таким образом, чтобы ее можно было тестировать (как единое целое), или, альтернативно, проверить это в тесте интеграции вместо единичного теста.

+0

Хорошо, спасибо за ваш совет. Я постараюсь сделать это. – user2439522

0

Вы не должны издеваться над вызовами JDBC - это может быть сделано, но это слишком сложно, и это не так важно. Вместо этого вы должны выполнить Mock метод deleteData, чтобы проверить другие методы, которые его называют.

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

5

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

В принципе, мы говорим об испытании интеграции, а не модульном тесте. И я не вижу, чтобы Мокито очень помог вам, хотя, конечно, Юнит.

В прошлом, как я протестировал такой код, с облегченной базой данных в памяти. Есть несколько из них, но тот, который я бы рекомендовал, - H2 (h2database.com). Это довольно быстро и легко использовать, как только у вас есть барабан H2 на вашем пути.

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

  1. Создать фиктивные таблицы для записей вызовов процедур,
  2. Создать фиктивную процедуру DEL_DATA, которая не делает ничего, кроме записи, что параметры его называли с в фиктивной таблице
  3. Выполнить метод
  4. Выберите из фиктивной таблицы, чтобы убедиться, что процедура была вызвана правильно.

С помощью H2 вы можете запускать такие тесты в режиме «в памяти», что означает, что в конце каждого теста нет необходимости в каком-либо этапе очистки.

+0

Еще одно преимущество запуска встроенной базы данных в памяти - это, по крайней мере, на порядок быстрее, чем при использовании традиционной настройки базы данных сервера/клиента. Это означает, что ваши тесты выполняются намного быстрее. –

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