Java 如何为开发测试配置Hibernate

我们是9位程序员，使用hibernate框架开发java Web应用程序， 但是，每次我们想要测试项目时，我们都会运行（在运行模式、调试模式）项目，我们必须等待Hibernate创建SessionFactory和所有关系查询，这样我们就有问题了！

---

我应该怎么做才能让Hibernate更快地工作？

需要多长时间？我知道这需要一些时间，但不会太长。如果花那么多时间，我看不出你能在这里做什么

您确定是sessionfactory在花费时间，而不是应用程序中的其他东西在启动时初始化吗

---

您可以使用单元测试来测试部分代码，从而减少整个应用程序的启动。

您能否详细说明所需的时间：

• 是一次，还是每次测试
• 你到底要谈多久
• 什么是休眠负载？（表格数量，或更好的列总数等）

根据您的答案，可以研究几个方向，例如通过巧妙的配置实际减少（恐怕只有百分之几）时间

但我最初的猜测是，您可能会有一个更聪明的举动，实际上没有为您的测试实例化Hibernate。那会解决一切问题，不是吗？虽然这样说似乎很愚蠢，但我们是这样做的：

• 我们将JUnit测试分为几个类别（基于项目、源目录或其他…）。每个都可以单独运行（如果需要，询问）
• 我们称一个测试类别为集成测试，它需要访问昂贵（缓慢或其他）的资源，如数据库、国外web服务或其他启动的软件（可能没有并发访问）、线程、IO、JMS、DLL、昂贵的许可证、x509证书、负载测量、超时。。。设置这些测试更为复杂，可能不是每个工作站都可以完成，执行这些测试需要花费更多的时间。每次开发人员开发这样的功能时，他都会经常运行相应的测试（或更多），并接受延迟。我们的自动构建每天都在运行，这就是我们确保回归检测的方式
• 我们称一个测试类别为单元测试。它不需要访问昂贵的资源，例如，它不会触发Hibernate初始化。每个开发人员都会一直执行这些测试，而且测试速度很快（对于一个大项目来说，几秒钟就足够了）！我们不必费心只选择其中一个

诚然，这种测试组织会影响应用程序设计和代码，但这也是当前最佳实践所规定的，因此我们可以从中获得许多好处。例如：

• 之前：调用dao进行数据库通信的业务算法可以如下所示：
• one=dao.readOne（）
• a=做算法a
• two=dao.readTwo（）
• b=do算法b
• if（b）dao.save（一，二，a，b）
• 之后：我们在不同的类或方法中划分了更多不同的职责：
• one=dao.readOne（）
• two=dao.readTwo（）
• （a，b）=执行算法AB（一，二）
  • a=执行算法a（一）
  • b=执行算法b（两个）
• if（b）dao.save（一，二，a，b）

以前，我们无法独立于数据库测试“DoAlgoAB”，因为它是包含数据库访问的全局过程的一部分（更重要的是，访问与逻辑混合在一起）

之后，“do algo AB”很容易在单元测试中测试

我们还发现，先进行只读数据库操作，然后进行处理，再进行只写数据库操作有很多优势

JUnit性能：如前所述

请注意，Daos测试可以通过IntegrationTesting完成。实际上，在我们的项目中，我们将JUnit重点放在单元测试上，只有很少的IntegrationTests，我们直接从UI测试它们中的大多数。。。集成测试ROI没有那么好；-）

短而集中的事务：我们可以有两个事务（和会话），例如，在复杂的只读阶段享受Hibernate身份保证。当算法修改实体时，Hibernate不会触发隐式更新（我们项目中的早期开发人员不知道这可能发生！）。如果算法决定不更新数据库，则没有时间将数据发送到数据库，无需取消该事务

算法的可重用性：在许多情况下，用于on计算的相应数据已经由以前调用的算法加载，因此从数据库重新加载它是一种浪费。此外，重新加载可能会携带不同的数据，从而导致脆弱的计算

。。。其他我现在不记得了；-）

Junit.org网站有许多用于测试策略的优秀资源。

---

我还喜欢优秀的Rainsberger书籍（），我绝对推荐它用于任何使用自动测试且有多个开发人员的项目。：-）

在.NET中，我通过IoC容器保存NHibernate SessionFactory。下次需要数据访问时，工厂已准备就绪。但这可能是一种不好的做法——我不确定。瓶颈是sessionfactory和Hibernate何时需要创建关系查询。有时不运行（sessionFactory=newannotationconfiguration（）.configure（）.buildSessionFactory（）；）这行代码，什么也不做（没有异常，没有运行）