Как протестировать "добавить" в DAO без использования "найти"и т. д.?

в следующем коде проблема в том, что я не могу проверить Дао.add () без использования Дао.список.)(size () и наоборот.

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

public class ItemDaoTest {

    // dao to test
    @Autowired private ItemDao dao;

    @Test 
    public void testAdd() {
        // issue -> testing ADD but using LIST

        int oldSize = dao.list().size();
        dao.add(new Item("stuff"));
        assertTrue (oldSize < dao.list().size());
    }

    @Test
    public void testFind() {
        // issue -> testing FIND but using ADD

        Item item = new Item("stuff")
        dao.add(item);
        assertEquals(item, dao.find(item.getId()));
    }
}
7
java unit-testing

4 ответов

Я думаю, что ваш тест-это действительные интеграционные тесты, как указано выше, но я бы использовал Add для помощи в тестировании Find и vice verse.. На каком-то уровне вы должны позволить себе доверять самому низкому уровню интеграции с вашей внешней зависимостью. Я понимаю, что в ваших тестах есть зависимость от других методов, но я нахожу, что методы Add и Find-это методы "низкого уровня", которые очень легко проверить. Они по существу проверяют друг друга, поскольку они в основном обратные методы.

Add может легко создавать предварительные условия для find

Find может проверить, что добавление было успешным.

Я не могу придумать сценарий, когда сбой в любом из них не будет пойман вашим тестом

2

ваш метод testAdd имеет проблему: это зависит от предположения, что ItemDao.список функционирует правильно, и все же ItemDao-это класс, который вы тестируете. Модульные тесты должны быть независимыми, поэтому лучше использовать простой JDBC-как сказал @Amir - для проверки, была ли запись введена в базу данных.

Если вы используете весну, то вы можете передать дальше AbstractTransactionalDataSourceSpringcontexttests для доступа к объектам JDBCTemplate и обеспечения отката после тест был выполнен.

1

Я использую direct JDBC (используя Jdbctemplate Spring) для тестирования методов DAO. Я имею в виду, что я вызываю методы DAO (которые являются Hibernate base), а затем подтверждаю их с помощью прямых вызовов SQL JDBC.

0

самый маленький тестируемый модуль для модульного тестирования на основе класса-это класс.

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

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

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

0