保持面向数据库的测试套件处于最新状态
本文关键字：于最新 最新 状态 套件 数据库 测试 | 更新日期: 2023-09-27 18:29:14
考虑一个以数据库为中心的服务的自动化单元测试套件。许多小部件可以在没有任何数据库连接的情况下进行单元测试，但能够插入真实的数据库快照（或多个快照）并针对它执行更大的集成场景也很有用。因此，一些关键测试包括一种与测试代码本身分离的执行前和执行后数据快照形式。
服务和数据库模式发展得很快。这会不断使测试数据无效，开发人员很难在不让缺陷行为蔓延到更新的快照中的情况下保持测试套件的最新状态。
通常，甚至不可能针对旧的（测试数据库）模式执行服务的较新版本；这可以通过具有两层数据库快照来解决，一层用于初始化（测试输入），另一层纯粹用于检查（例如，预期的测试输出）。初始化模式/数据可以与应用程序一起自动升级，但显然不是预期的输出数据。
我已经读过几次了，但我希望能链接到更多关于这个主题的阅读，以及人们的经验、技术和方法论，特别是在Java、.NET以及可能的纯数据库环境中。
这个问题故意有点宽泛，因为我不知道我会从中学到什么，但这里也有一个更窄的版本：
是否有任何广泛使用的Java或.NET框架可以让开发人员更容易地区分模式差异和行为（数据）差异，并半自动地将现有的测试数据更新为新的模式
-
这是一个组织测试套件的问题，而不是拥有一个监控数据库更改的框架。例如，如果您使用Hibernate/EJB持久性模型，那么在执行测试套件之前，您可以从对象映射创建一个数据库（例如使用Hbm2Ddl）。然后，每个测试都通过保存实体（即不使用任何直接SQL）创建必要的对象。基本上说，在这种情况下，您不直接处理数据库，只通过应用程序中的持久层来处理。在执行结束时，将删除数据库架构。
-
另一方面，这是一个过程问题。每次数据库更改都必须保持测试的完整性。不像有些人在不考虑测试完整性的情况下更改数据库。基本上，如果源中的任何更改破坏了测试，则无论是代码还是数据库结构更改，都不能接受。
换言之，在开发过程中应该有一个特定的规程+通过持久层建立和工作的适当的测试环境（即，不是一个测试数据库，它是一个生产数据库的转储，带有没有或只有最小设置/拆卸的测试）。