这取决于 :-)
如果您的DAO类仅包含从数据库中获取实体所需的代码,则最好在单独的集成测试*中测试它们.要进行单元测试的代码是"业务逻辑",您可以使用模拟DAO对其进行单元测试.
[更新]例如,使用EasyMock,您可以轻松地为特定类设置模拟(具有类扩展,甚至可以模拟具体类),将其配置为从特定方法调用返回特定对象,并将其注入到您的类中待测试.
EasyMock网站现在似乎已经关闭了,希望它很快就会回来 - 然后你可以查看文档,这是恕我直言,非常干净和彻底,有很多代码示例.在你的问题中没有太多细节,我无法给出更具体的答案.[/更新]
如果,OTOH,DAO也包含业务逻辑,那么您的最佳选择 - 如果您可以这样做 - 将重构它们并将业务逻辑移出DAO,那么您可以应用之前的策略.
但最重要的是,始终牢记单元测试的座右铭"测试可能会破坏的一切".换句话说,我们需要优先考虑我们的任务,并集中精力编写测试,以最少的努力提供最大的好处.首先为最关键,最危险的代码部分编写单元测试.代码 - 在您看来 - 如此简单,它不可能破坏在列表的下方.当然,最好咨询经验丰富的开发人员,了解具体的代码 - 他们可能知道并注意到您可能不知道的陷阱和问题.
*单元测试应该是轻量级的,快速的并且尽可能地与环境隔离.因此,包括对真实数据库的调用的测试不是单元测试,而是集成测试.尽管从技术上讲它们可以使用JUnit(例如DbUnit)构建和执行,但它们要比正版单元测试复杂得多,并且要慢几个数量级.有时,这使得它们不适合在每次小代码更改后执行,因为常规单元测试可以(并且经常应该)使用.