2016-01-11 4 views
0

Я пытаюсь сделать модульный тест на DAO class с использованием Mockito. Я уже написал некоторые модульные тесты, но не на DAO class, используя некоторую базу данных (в данном случае JDBC и MySQl).Испытание класса DAO, использующего JDBC с Mockito

Я решил начать с этого простого метода, но сейчас я не понимаю, какие хорошие практики, и я не знаю, с чего начать.

Я не знаю, важно ли это в этом случае, но проект использует Spring Framework.

public class UserProfilesDao extends JdbcDaoSupport { 

    @Autowired 
    private MessageSourceAccessor msa; 

    public long getUserId(long userId, int serviceId) { 
     String sql = msa.getMessage("sql.select.service_user_id"); 
     Object[] params = new Object[] { userId, serviceId }; 
     int[] types = new int[] { Types.INTEGER, Types.INTEGER }; 
     return getJdbcTemplate().queryForLong(sql, params, types); 
    } 
} 
+0

На самом деле, если вы реализуете часть сервиса вы можете думать о новом способе тестирования услуг, помимо использования его на WebService проекте, теперь код показывает весной объект JDBC дао, который ничего не значит, связанное к вашей тестовой среде? – Hayra

+0

@ Сабир Хан, я никогда не писал модульный тест на классе DAO. Я попытался провести тест с использованием HSQLDB, но после этого я понял, что это не единичный тест, а интеграция. Я задаю здесь несколько советов и несколько простых примеров. – NoSuchUserException

ответ

2

Если вы действительно хотите протестировать DAO, создайте базу данных в памяти. Заполните его ожидаемыми значениями, выполните запрос внутри DAO и убедитесь, что результат верен для предыдущих вставленных значений в базе данных.

Смещение Connection,, PreparedStatement слишком тяжелое, и результат не так, как ожидалось, потому что вы не имеете доступа к реальному дБ.

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


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

Считают, что насмешливый классы баз данных (PreparedStatement, Statement, ResultSet, Connection) представляет собой длительный процесс, и вы не доказанным, что он работает, как и следовало ожидать, потому что вы не тестируете правильный формат вашего SQL над SQL двигателя.

Вы также можете взглянуть на article of Lasse Koskela, говорящий о модульном тестировании daos.


Чтобы проверить DAO вам нужно:

  • Пустой базы данных (не обязательно для в дб памяти)
  • Заполните базу данных с помощью примера данных (автоматического блока с БД, заключенный в @BeforeClass или @Before метод)
  • Выполнить тест (с JUnit)

Если йо Вы хотели бы формально отделить реальные модульные тесты от тестов интеграции, вы можете перенести тесты DAO в отдельный каталог и протестировать их при необходимости и в тестах интеграции.


Возможные в базе данных памяти, которая имеет различные режимы совместимости является H2 со следующей сочетаемостью базы данных:

  • IBM DB2
  • Apache Derb
  • HSQLDB
  • MS SQL Server
  • MySQL
  • Oracle
  • PostgreSQL
+0

Если я использую базу данных в памяти, тест не будет интеграцией? – NoSuchUserException

+0

Я добавляю свои комментарии к ответе –

+0

OK! Какой самый правильный способ проверить DAO? – NoSuchUserException

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