域类的自动测试（非单元测试）

Question

当前问题

请参阅相关帖子：What can go wrong in hibernate domain classes – so that we need to (unit) test them? 在我的新J2EE项目中，我试图测试（不一定是单元测试）我开始编写的域对象。它们不涉及很多业务逻辑（业务逻辑是DAO对象之上的业务服务的一部分），通过测试，我基本上确保域对象的完整性，我试着通过测试DAO来做到这一点方法。请注意，我无法使用JUnit等测试域对象，因为它们在我的情况下没有任何方法，并且它们具有属性和hibernate映射注释。

例如，让我考虑 Patient 域对象。在这种情况下， PatientDAO 正在处理Patient域对象的CRUD操作。以下是方法（不完整并打算稍后添加更多测试边界条件）。

注意：我不是将这些称为单元测试用例，它们可能是迷你集成测试等。我很好，这种方法可用于测试域对象。

PatientDAOTest类包含： - testCreatePatient（）; - testUpdatePatient（）; - testFindPatient（）; - testDeletePatient（）;

PatientDAO课程包含： - createPatient（）; - updatePatient（）; - findPatient（）; - deletePatient（）;

让我们考虑测试域对象中的updateMethod（）的testUpdatePatient（）方法。现在，我将如何实现testUpdatePatient（）方法？好吧，我在想： 1.使用'findPatient（）'域方法获取现有患者 2.使用新的详细信息更新患者记录 3.使用“updatePatient（）”域方法将其保存回数据库 4.使用'findPatient（）'域方法从数据库中检索患者记录 5.断言更新的数据

问题

正如您所看到的，我在测试中使用数据库，我很好，但这种方法有什么问题吗？

关于这种方法，我的真正问题（读作问题）是什么？

我需要在测试' updatePatient （）'时使用' findPatient （）'方法（实际上是2次）。这是我不喜欢的事实，我必须在测试方法时使用另一种方法，而另一种方法本身可能是错误的。当我尝试测试其他CRUD方法时，同样的故事重复出现。

或者，我可以编写select sql查询从数据库中获取患者记录，以便从测试方法中断言（在更新被触发后），但它只是打败了使用hibernate的整个目的（以减少SQL编码工作）因此，我不喜欢这种方法。

我的问题是，通常依赖其他方法来测试特定方法，这是一个不错的方法吗？如果这是错误的，我应该如何在我的域对象中实际测试ORM映射。

感谢您对这么长篇文章的评论和道歉。

Answer 1

根据我的经验，回答你的主要问题很简单，但你还有其他几个概念问题。

1. 包含使用另一个功能（updatePatient）的功能（findPatient）插入测试是完全可以的，但是，如果您有另一个测试，则仅包含findPatient本身。
2. 对于DB集成测试的有条理部分，您可以考虑使用deditaced自动测试DB，清除所有数据并将其作为单元测试的setUp初始化为所需状态。使用纯SQL脚本（TRUNCATE TABLE患者; INSERT INTO患者......）使用样本初始数据初始化数据库 - 我以前做的是在几个命名的DB初始数据状态之间切换（例如“cleanDB”，“twoPatientsSimple1”，“twoPatientsLenkedToInsuranceContracts1” “等）。这里的要点是，您的数据库在单元测试期间会发生变化，并且在测试之前使用纯ROLLBACK进入状态并不能确保您想要的确切状态（例如，您可能在测试期间明确提交，并且您的数据进入不是初始状态）。您还可以在测试更改后使用测试来确保数据库状态，再次使用纯SQL。使用这种方法进行测试通常执行起来很慢并且难以维护（除非您有一套我们自己的帮助工具），但它让您对数据和行为充满信心。清楚地完成此操作后，它可以在UI /功能测试期间为您节省大量时间和困惑。它可能会很糟糕，但是当你稍微玩一下时，最终会得到一组简单的DB状态数据（例如在测试用例中表示为TSV / CSV）“initState”和“expectedState”，你只需使用这些在测试行为之前/之后进行初始化/比较。
3. 对于域对象（未与DB集成）的真正单元测试，您必须模拟DAO / Repository / DataMapper类，例如使用简单的List泛型（createPatient将其添加到列表等中。）
4. 对于ORM本身（您自己的，第三方或您的扩展程序）的集成测试，您将使用第2点中的方法，其中一些示例数据（不一定是您的域对象）足够复杂，可以让您对你的ORM如何运作。例如。 Microsoft Entity Framework在早期阶段工作非常不可预测，因此编写通常使用的功能的完整集成测试可以避免调试ORM本身的错误和问题，并向您展示ORM在各种条件下的行为。