可维护性数据库集成测试

Question

的我正在开发一个ETL过程，从一个数据库到数据仓库中提取业务数据。该应用程序不使用NHibinate，Linq to Sql或Entity Framework。该应用程序具有自己生成的数据访问类，它们生成执行CUID所需的SQL语句。

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

我想编写一个生成测试数据（Arrange）的程序，比执行ETL过程（Act）和验证数据仓库（Assert）。

我不认为这是很难写这样的程序。然而，我担心的是，过去我的公司曾试图做类似的事情，最终导致一系列不可维护的单元测试，这些测试经常因为添加新功能而对数据库模式进行了许多新的更改而失败。

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

我很想从社区那里得到任何反馈意见，让我写出这样易于维护的集成测试。有些想法我有：

1. 保存在版本控制备份测试数据库（TFS），开发人员需要在有数据更改源或数据仓库来修改备份数据库。

2. 开发人员需要通过手动测试程序（本例中为C＃）来维护测试数据。该程序将为开发人员生成测试数据提供一个基本框架。

3. 当测试数据库初始化时，它会生成随机数据。开发人员需要编写代码来覆盖某些随机生成的数据，以确保测试通过。

我欢迎任何建议 感谢

Answer 1

首先，让我们说，我认为这是一个很好的计划，以及如何使用Oracle & PL/SQL几年前，我已经做了类似的事情。恕我直言，你的问题主要是组织的一个，而不是技术：

• 你必须有人负责扩展和维护测试代码。
• 负责维护测试数据必须是明确的（并提供了简单的测试数据维护机制;同样适用于任何可能需要的验证数据），整个团队应该知道，没有代码将进入生产环境
• 只要测试失败。如果测试失败，球队的首要任务是修复（代码或测试，无论是右）。训练他们不要在任何新功能上工作，只要测试中断！
• 修复了一个错误之后，修复它的人应该很容易验证之前失败的集成部分之后没有失败。这意味着，应该可以从任何开发人员机器（或至少其中的一部分）轻松地运行整个测试并快速地运行该应用程序。 如果您的测试过大，快速可能会导致ETL过程出现问题，因此请专注于使用尽可能少的数据测试许多事情。也许你可以把整个测试分解成可以一步一步执行的小块。

Answer 2

嘿DSUM， allthough我真的不知道你的整个ETL的架构，我会说，是集成测试应该只在您的测试过程中又迈进了一步。

即使第一次遇到的单元测试结果混乱，你应该记住，对于很多情况来说，单个单元测试是最好的检查地点。或者你是否想要将整个集成测试拆分为三路或三路？其他更深层次的内容，以保证三种条件中的每一种的正确流动？

凌乱的单元测试只是凌乱的生产代码的结果。不要感到生气。这只是我的看法。单元测试强制编码人员保持干净的编码风格，并保持整个事情的可维护性。

所以......我的目标是，您不仅要考虑对整体进行集成测试，因为单元测试（如果它们以正确的方式使用）可以更专注于问题。

Regards， MacX