高级开发人员告诉我，但对 Hibernate 的经验较少，将实体管理器连接到您的单元测试套件以用于设置您的数据库是不合法的做法。 ...但我持怀疑态度，因为我已经在几个地方工作过。请注意，Hibernate 已被用于设置测试 H2 数据库。
我被要求“证明”它是合法的。我怎样才能做到这一点？这是社区标准的做法吗？有谁知道我可以使用的好链接？虽然我自己也在寻找这样的人，但我在这里闻到了一点宗教的味道，所以我可能需要一个真正的杀手，或者可能需要大量的人。
【问题讨论】：
标签： java hibernate unit-testing testing
您的高级开发人员指的是适当的白盒测试。
当您进行单元测试时，您希望只测试给定的单元。当您开始涉及诸如数据库或某些外部 Web 服务之类的东西时，这会变得更加复杂。但是，重点仍然存在：您仍然只想测试单元测试所针对的一段代码；不是一些数据库。
您是否对 hibernate 或您的数据库有信心是无关紧要的。您需要“模拟”数据库事务、EntityManager 等。我会按照 EasyMock 的思路进行研究。真的，这完全取决于您想使用什么。如果您在 Google 上搜索“mock junit”，您可能会找到一个结果列表，您可以在其中选择适合您的框架。不过，适合您的框架有点超出本次讨论的范围。
一旦你找到了你想要使用的东西，你的想法是在你的单元测试中，而不是获得一个真正的 EntityManager，你有一个你已经模拟的模拟对象：
文档说如果我调用方法 C 会发生 A，所以我告诉了模拟框架它可以为我伪造它，所以我不必依赖单元测试之外的东西
您想像这样模拟一个对象的原因是因为您不能依赖该单元之外的任何其他代码来正常工作。不管你期望什么，不管文档说你应该期望什么，如果代码写得不好，或者在你的情况下，如果数据库由于某种原因失败，那么单元测试就会失败。您可以看到这可能是一个问题，因为您的函数可能完美执行，但由于数据库失败而失败。这不是单元测试应该如何工作的 - 这就是为什么它被称为单元测试......一次只测试一个单元。
总是模拟复杂的对象或功能。留下像 String#equals(java.lang.Object) 这样的东西是可以的。这样做，你想找到一个好的中间立场。如果你模拟了太多的单元测试，那么你就会对单元测试失去信心，因为你的单元测试实际上并没有调用你的任何实际代码。如果你没有足够的模拟，那么你没有正确地进行单元测试，并且你的单元测试依赖于与你的代码无关的事情（即数据库故障，第三方代码写得不好等）。
您的高级开发人员是正确的。如果您在单元测试中使用真正的 EntityManager，那么您实际上根本没有进行单元测试。
【讨论】：