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