Есть ли ряд тупиков/насмешек для JDBC, доступного где-нибудь?

Похоже на вас » есть ли проблемы в самом коде DAO? В противном случае слой DAO - очевидное место для насмешек, но если вы пытаетесь протестировать DAO, вам нужно будет имитировать то, что находится ниже.

Лично я стараюсь держаться подальше от насмешек над большими , сложные библиотеки; если вам действительно нужно протестировать уровень DAO напрямую, а DAO работает напрямую с JDBC, у вас есть три очевидных варианта:

1. Запустить интегрированный тест, который включает DAO и JDBC вместе с базой данных
2. Добавить уровень выше JDBC с более тонким интерфейсом, лучше подходит для имитации.
3. Используйте JDBC-имитаторы либо собственного написания, либо некоторых из перечисленных выше элементов.

Я почти всегда выбираю №1 или №2. Поскольку существует множество возможностей ошибок в искаженном синтаксисе SQL и т.п., я склоняюсь к пункту №1. Однако я понимаю, что вы просите не об этом. ;)

1. Запустите интегрированный тест, который включает DAO и JDBC вместе с базой данных.
2. Добавьте слой над JDBC с более тонким интерфейсом, лучше подходящим для имитации.
3. Используйте JDBC-имитаторы собственного написания или некоторых из пункты, перечисленные выше.

Я почти всегда выбираю №1 или №2. Поскольку существует множество возможностей ошибок в искаженном синтаксисе SQL и т.п., я склоняюсь к пункту №1. Однако я понимаю, что вы просите не об этом. ;)

1. Запустите интегрированный тест, который включает DAO и JDBC вместе с базой данных.
2. Добавьте слой над JDBC с более тонким интерфейсом, лучше подходящим для имитации.
3. Используйте JDBC-имитаторы собственного написания или некоторых из пункты, перечисленные выше.

Я почти всегда выбираю №1 или №2. Поскольку существует множество возможностей ошибок в искаженном синтаксисе SQL и т.п., я склоняюсь к №1. Однако я понимаю, что вы просите не об этом. ;)

Вы можете протестировать базу данных напрямую с помощью dbunit .

Хотя я в целом большой поклонник модульного тестирования, я обнаружил, что оно имеет ограниченную ценность для DAO.

Я видел, что, хотя тесты вполне можно писать (используя любой из имитирующих API - JMock , EasyMock и т. Д.), Они обычно работают прямо - off (логика настолько проста, как они не могли) ломаться только тогда, когда вы меняете код (например, добавляете значение), и это просто делает их бременем для базы кода.

Я думаю, это потому, что мои DAO обычно имеют форму:

• получить соединение.
• создать оператор.
• установить значения.
• прочитать значения (для операций загрузки).
• очистка .

Затем вы делаете предположения о том, как драйвер JDBC будет / работает (работает), и вы получаете тест, который ' на самом деле ничего не делает, кроме тестирования, когда вызывается простой код в том порядке, в котором он объявлен.

Ошибки, происходящие из DAO, обычно возникают в базе данных (ключевые нарушения, ошибки в сохраненных процессах и т. Д.), И, если вы не используете систему в целом, вы не увидите этих ошибок.

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