Question

在下面的代码中，问题是，我无法在不使用 dao.list（）。size（）的情况下测试 dao.add（），反之亦然。

此方法是正常还是不正确？如果不正确，怎么改进？

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 -as @Amir说 - 来验证是否在数据库中引入了记录。

如果您正在使用Spring，则可以在AbstractTransactionalDataSourceSpringContextTests上中继以访问JDBCTemplate工具并确保在执行测试后进行回滚。

Answer 3

我使用直接JDBC（使用Spring的JdbcTemplate）来测试DAO方法。我的意思是我调用DAO方法（它们是Hibernate基础），然后使用JDBC直接SQL调用来确认它们。

Answer 4

基于类的单元测试中被测试的最小单元是一个类。

要了解原因，请考虑到理论上可以通过绕过，存根或模拟它们来隔离所有其他方法来测试类的每个方法。有些工具可能不支持;这是理论而非实践，假设他们这样做。

即便如此，以这种方式做事也不错。单个函数的规范本身将在模糊无意义和冗长不可理解之间变化。只有在不同函数之间的交互模式中，才会存在比您可以有效地用于测试它的代码更简单的规范。

如果您添加一个项目并且报告的项目数量增加，那么一切正常。如果有某些方法无法正常工作，但是所有的交互模式都存在，那么你就缺少一些必要的测试。

如何在不使用“查找”等的情况下测试DAO中的“添加”？

4 个答案: