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

Question

В следующем коде проблема в том, что я не могу проверить dao.add () без использования dao.list (). 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()));
    }
}

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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