Hibernate Generic DAO - 测试生成的 SQL 是否正确
我有一个 DAO 基础设施，如下：
StoreDao、CouponDao、PersonDao。
所有这些都从具有大量功能的 GenericDao 扩展而来（使用 Java 泛型）。 这里有一些解释 - [http://www.ibm.com/developerworks/java/library/j-genericdao/index.html][1]
当在 StoreDao 上调用 getAll() 时，实际调用的是 GenericDao 的 getAll()它将某些默认的 where 子句（如 active=true,expires>now()）附加到要执行的现有 HQL 查询中。
我们有一堆在 setup() 中创建数据的 Dao 测试，还有一堆对响应进行断言的测试。不完全是单元测试，因为数据库没有被模拟，但我猜可以称为集成测试。
我的一位队友创建了一个测试基础设施来测试生成的 sql 查询是否准确。他的做法如下：
有一个自定义的 Hibernate 拦截器来拦截 onPrepareStatement()，使用 Hibernate 的 ASTParser 创建要执行的查询的 XML 结构，然后使用 XPaths 来验证查询，例如，查看是否确定字段存在于 where 子句中，连接正确等等。
我们这样做是为了单独测试 Generic Dao。为此，我们必须创建 GenericDomain、GenericChildDomain、GenericDomain.hbm.xml 以及支持这些的表。
问题：
这值得吗？除非我们已经完全模拟了我们已经拥有的所有单元测试的数据库，否则我不认为我们有理由创建这个基础设施。
我们怎么能不使用我们已有的基础设施来测试 HQL。如果您想确保 active=true 已附加到查询中，只需确保 DAO 不会返回 active=false 的数据即可。
最后，我们在这里所做的主要是针对 Hibernate 的，如果我们决定用 IBatis/JPA-EclipseLink/NoSQL 替换我们的 DAO，那么这些内容大部分都会被丢弃。
最后，我们为什么要发明这样的东西。这不是一个相当普遍的问题吗？难道没有人已经构建了解决方案吗？
I have a DAO infrastructure as follows:
StoreDao, CouponDao, PersonDao.
All these extend from a GenericDao which has the bulk of the functionality(using Java Generics).
kind of explained here - [http://www.ibm.com/developerworks/java/library/j-genericdao/index.html][1]
When getAll() is called on StoreDao, what's actually called is GenericDao's getAll() which appends certain default where clause like active=true, expires>now() to the existing HQL query to be executed.
We have a bunch of Dao tests which create data in their setup(), have a bunch of tests that assert on the response. Not exactly unit tests since the database isn't mocked, but can be called integration tests i guess.
One of my team mates has created a testing infrastructure to test whether the sql queries generated are accurate. The way he does this is as follows:
Have a custom Hibernate interceptor that intercepts onPrepareStatement(), uses Hibernate's ASTParser to create an XML structure of the Query about to be executed and then use XPaths to validate the query, for instance, look if certain fields are present in the where clause, the joins are correct etc.
We are doing this to test the Generic Dao in isolation. For this, we're having to create GenericDomain, GenericChildDomain, GenericDomain.hbm.xml alongwith the tables backing these.
Questions:
Is this worth it? Unless we have completely mocked out the database for all our unit tests that we already have, I don't see a reason for us to create this infrastructure.
How can we not test the HQLs with the infrastructure we already have. If you want to make sure that active=true was appended to the query, just make sure that the DAO does not return data with active=false.
Lastly what we're doing here is heavily hibernate specific which will mostly be thrown away if we decide to replace our DAOs with say IBatis/JPA-EclipseLink/NoSQL.
Finally, why do we have to invent something like this. Isn't this a fairly common problem? Isn't there a solution already built by someone out there?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在测试生成的 SQL 时，我的投票是“不要这样做”。除非您对以特定方式生成查询有非常具体的需求（也许是在应用程序的性能高度敏感的部分），否则没有真正的需要。大多数情况下，您在此级别的测试感兴趣的是事物根据它们的映射方式正确保存和加载，并且您的查找器方法找到了它们应该找到的东西。您似乎倾向于启动 hibernate 并针对真实数据库练习 DAO，我认为这是正确的方法。
On the testing of generated SQL, my vote is, "Don't do it." Unless you have a highly specific need for a query to be generated in a particular way--in a highly performance-sensitive piece of an app, perhaps--there's no real need. Mostly what you're interested in testing at this level is that things save and load properly according to how they're mapped and that your finder methods find the things they should. You seem to be leaning in the direction of just starting up hibernate and exercising your DAOs against a real database, and I'd say that's the right approach.