Как макетировать классы, созданные как локальные переменные

Question

Я пишу тесты для бизнес-метода, который вызывает некоторые классы DAO для выполнения операций над базой данных.

Этот метод сначала извлекает соединение JDBC из объекта DataSource. Одно и то же соединение передается всем экземплярам DAO, поэтому я могу использовать его для управления транзакцией. Итак, если все работает правильно, я должен вызвать commit () над объектом подключения.

Я хотел бы проверить, вызывается ли commit (), поэтому я подумал создать ожидание (я использую JMock), которое это проверяет. Но поскольку класс Connection не является непосредственным соседом моего бизнес-класса, я не знаю, как это сделать.

Кто-то знает, как это побороть? Для этого есть какое-то средство JMock или альтернативный дизайн, позволяющий преодолеть это?

Спасибо

Answer 1

Мне трудно из вашего описания точно сказать, как составлены ваши классы, но источник данных должен быть внедрен в ваш класс DAO, либо через его конструктор, либо через метод setDataSource().

Это позволит вам тестировать DAO изолированно и позволит создать фиктивный источник данных в модульном тесте и передать его тестируемому DAO.

Answer 2

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

Answer 3

Я бы определенно рекомендовал вам использовать spring-jdbc вместо того, чтобы пытаться писать этот код самостоятельно. Это обеспечит правильное закрытие соединения, оператора и набора результатов. Spring также имеет отличное управление транзакциями, поэтому вам не нужно беспокоиться об этом.

Например, взгляните на этот типичный оператор обновления с использованием spring-jdbc:

public void updateName(int id, String name) {
    getJdbcTemplate().update(
            "update mytable set name = ? where id = ?", 
            new Object[] {name, new Integer(id)});
}

Answer 4

Рефакторинг, чтобы соединение вводилось в Дао, а Дао - в бизнес-класс. Затем вы можете издеваться над Дао и / или Соединением. Вы можете легко написать свой собственный макет, который расширяет Connection и переопределяет connect (), чтобы установить логическое значение, которое вы позже получите с помощью метода записи, такого как wasConnectCalled ().

Answer 5

@ Пол поддержал. И после того, как вы разделили управление соединением, вы можете записать оставшуюся часть поведения в обратном вызове, который вы передаете в то, что владеет соединением - как UnitOfWork. Владелец соединения обрабатывает транзакцию и передает соединение в UnitOfWork. Транзакции в одном месте - легко тестировать, UnitOfWork - в другом месте, тестируется с фиктивным соединением.

Answer 6

Заставить бизнес-класс извлекать локальные переменные из фабрики глобальных / статических объектов. Таким образом, вы можете перевести фабрику в тестовый режим и заставить ее возвращать фиктивные объекты вместо реальных.

Это должно сделать это.