域类的自动测试(非单元测试)

Question

当前问题

请参考相关文章：休眠域类中会出现什么问题——所以我们需要（单元）测试它们？在我的新 J2EE 项目中，我正在尝试测试（不一定是单元测试）我开始编写的域对象。 它们不涉及太多的业务逻辑（业务逻辑是 DAO 对象之上的业务服务的一部分），通过测试，我基本上确保了域对象的完整性，我尝试通过测试 DAO 方法来做到这一点。 请注意，我无法使用 JUnit 等测试域对象，因为它们在我的情况下没有任何方法，并且它们具有属性和休眠映射注释。

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

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

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

PatientDAO 类包含：- 创建患者（）;- 更新患者（）;- 查找患者（）;- 删除患者（）;

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

问题

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

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

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

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

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

感谢您对如此冗长的帖子的评论和道歉。

Answer 1

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

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