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

在下面的代码的问题是，我无法测试dao.add（）不使用dao.list（）。大小（），反之亦然。如何在不使用“查找”的情况下测试DAO中的“添加”？

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

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())); 
    } 
}

来源

2012-03-30 Xorty

您是在集成或单元测试之后？ – davidfrancis 2012-03-30 22:44:19

你告诉我:)在这种特殊情况下 - 只使用常识似乎更像是对我的集成测试。但是，你知道，毕竟我只是想确保我的DAO工作，就是这样。 – Xorty 2012-03-31 01:18:19

是的，这是一种痛苦。由于dao具有的依赖性，不确定是否可以结束单元测试。 dao如何工作？我会亲自尝试避免让你的测试依赖于外部数据库，并尝试存根或模拟数据库访问层，如其中一个答案中的建议。话虽如此，但它从来没有像真正的分贝依赖集成测试那样令人放心。 – davidfrancis 2012-03-31 10:21:18

我认为你的测试是有效的集成测试，如上所述，但我会用Add来帮助测试Find和反之。在某些级别上，你必须允许自己将信任放在最低级别整合到你的外部依赖。我意识到在测试中存在对其他方法的依赖关系，但我发现Add和Find方法是非常容易验证的“低级”方法。他们基本上是相互检验的，因为他们基本上是反方法。

添加可以轻松地构建先决条件找到

查找可以验证一个附加成功。

我不认为其中任何一个故障就不会被你的测试

来源

2012-03-30 22:49:33 TGH

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

来源

2012-03-30 20:42:56

但是这意味着仅仅为了测试而添加未经测试的JDBC代码行......：| – Xorty 2012-03-30 20:46:41

你testAdd方法有一个问题：它取决于ItemDao.list功能正常，然而ItemDao是你正在测试的类的假设。单元测试意味着独立，所以更好的方法是使用普通的JDBC -as @Amir表示 - 来验证记录是否在数据库中引入。

如果你使用Spring，你可以中继上AbstractTransactionalDataSourceSpringContextTests访问JdbcTemplate的设施，并执行测试后保证回退。

来源

2012-03-30 20:50:46

最小的单元测试抓到基于类的单元测试场景的一类。

想知道为什么，认为你可以，理论上，通过绕开，测试框架或者模拟测试这些类的每个方法脱离所有其他方法。有些工具可能不支持;这是理论不实践，假设他们这样做。

即便如此，做的事情，这样会是一个坏主意。单独的功能本身的规范将在模糊的无意义和冗长的不可理解之间变化。只有在不同函数之间的交互模式中，才会存在比可以用来测试它的代码更简单的规范。

如果您添加项目，并报告增加项目的数量，一切正常。如果有某些方法可能无法正常工作，但所有交互模式都成立，那么您就错过了一些必要的测试。

来源

2012-03-31 01:17:06 soru

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

回答

相关问题