我有一个DAO基础设施如下:
StoreDao, CouponDao, PersonDao
所有这些都是从具有大部分功能(使用Java泛型)的GenericDao扩展而来的。这里有点解释- [http://www.ibm.com/developerworks/java/library/j-genericdao/index.html][1]
当在StoreDao上调用getAll()时，实际调用的是GenericDao的getAll()，它将某些默认的where子句(如active=true, expires>now())附加到要执行的现有HQL查询中。
我们有一堆Dao测试在它们的setup()中创建数据，有一堆测试在响应上断言。不完全是单元测试，因为数据库没有被模拟，但我猜可以称为集成测试。
我的一个团队成员创建了一个测试基础设施来测试生成的sql查询是否准确。他这样做的方法如下:
有一个自定义Hibernate拦截器，它拦截onPrepareStatement()，使用Hibernate的ASTParser创建即将执行的查询的XML结构，然后使用xpath验证查询，例如，查看where子句中是否存在某些字段，连接是否正确等。
我们这样做是为了孤立地测试泛型Dao。为此，我们必须创建GenericDomain, GenericChildDomain, GenericDomain.hbm.xml以及支持它们的表。
问题:
这值得吗?除非我们已经为我们已经拥有的所有单元测试完全模拟出数据库，否则我不认为我们有理由创建这个基础设施。
我们怎么能不用我们已经拥有的基础设施来测试hql呢?如果希望确保将active=true添加到查询中，只需确保DAO不返回带有active=false的数据。
最后，如果我们决定用IBatis/JPA-EclipseLink/NoSQL取代我们的dao，那么我们在这里所做的是非常特定于hibernate的。
最后，为什么我们要发明这样的东西?这不是一个很常见的问题吗?不是已经有人提出解决方案了吗?
对于生成的SQL的测试，我的建议是"不要这样做"。除非您非常需要以特定方式生成查询(也许是在应用程序中对性能非常敏感的部分)，否则没有真正的需要。在这个级别上，您最感兴趣的测试是根据它们的映射方式正确地保存和加载内容，以及finder方法找到它们应该找到的内容。您似乎倾向于启动hibernate并针对真实的数据库运行dao，我认为这是正确的方法。