数据库集成测试的可维护性答案

【问题标题】：Maintainability of database integration testing数据库集成测试的可维护性
【发布时间】：2011-01-28 06:50:15
【问题描述】：

我正在开发一个 ETL 流程，将业务数据从一个数据库提取到数据仓库。该应用程序未使用 NHibinate、Linq to Sql 或实体框架。该应用程序有自己生成的数据访问类，这些类会生成执行 CUID 所需的 SQL 语句。

正如想象的那样，编写生成自定义 SQL 的代码的开发人员很容易犯错误。

我想编写一个程序来生成测试数据 (Arrange)，而不是执行 ETL 过程 (Act) 并验证数据仓库 (Assert)。

我认为编写这样的程序并不难。然而，我担心的是，在过去，我的公司曾尝试做类似的事情，并最终导致一系列不可维护的单元测试不断失败，因为随着新功能的添加，数据库架构发生了许多新的变化。

我的计划是编写一个在构建机器上运行的集成测试，而不是任何单元测试来确保 ETL 过程正常工作。由于确定数据如何加载到数据仓库的业务逻辑，测试数据不能完全随机生成。我们有自定义开发工具，可以在数据库定义发生变化时生成新的数据访问类。

我希望社区提供任何反馈，让我就编写易于维护的集成测试提供建议。我的一些想法：

我欢迎任何建议谢谢

【问题讨论】：

【解决方案1】：

你好，尽管我并不真正了解 ETL 的整个架构，但我想说，集成测试应该只是测试过程中的另一个步骤。

即使第一次遇到的单元测试一团糟，您也应该记住，在许多情况下，单个单元测试是检查的最佳位置。还是您想将整个集成测试拆分为三路案例或某事。其他更深入，以保证三个条件中的每一个都正确流动？

凌乱的单元测试只是凌乱的生产代码的结果。不要觉得被冒犯了。这只是我的意见。单元测试迫使编码人员保持简洁的编码风格，并使整个事情更易于维护。

所以...我的目标是，您不仅要考虑对整个事物进行集成测试，因为单元测试（如果以正确的方式使用）可以更详细地关注问题。

问候， MacX

【讨论】：

你是绝对正确的@MacX。在创建和维护集成、功能和单元测试大约 10 年之后，您通常可以从单元测试中获得更多收益。集成测试也有很好的价值，但它不像其他测试类型那样可维护。

【解决方案2】：

首先，假设我认为这是一个很好的计划，并且几年前我使用 Oracle 和 PL/SQL 做过类似的事情。恕我直言，您的问题主要是组织问题，而不是技术问题：

您必须有人负责扩展和维护测试代码。
维护测试数据的责任必须明确（并提供易于维护测试数据的机制；同样适用于您可能需要的任何验证数据）
整个团队都应该知道，只要测试失败，任何代码都不会进入生产环境。如果测试失败，团队的首要任务应该是修复它（代码或测试，无论是正确的）。只要测试中断，就训练他们不要使用任何新功能！
修复错误后，修复错误的人应该很容易验证之前失败的集成部分在之后不会失败。这意味着，应该可以快速从任何开发人员机器（或至少部分机器）轻松运行整个测试。如果您的测试太大，Quick 可能会给 ETL 流程带来问题，因此请专注于用尽可能少的数据测试很多东西。也许您可以将整个测试分成更小的部分，这些部分可以逐步执行。

【讨论】：

【解决方案3】：

如果要在ETL中进行数据集成测试时维护数据，我们也可以按照这些步骤进行，因为ETL流程和相关应用程序的集成测试涉及其中。例如：

1.在源系统中设置测试数据。 2.执行ETL过程，将测试数据加载到目标中。 3.查看或处理目标系统中的数据。 4.验证数据和使用数据的应用程序功能

【讨论】：