我正在开发一个 ETL 流程，将业务数据从一个数据库提取到数据仓库。该应用程序未使用 NHibinate、Linq to Sql 或 Entity Framework。应用程序有自己生成的数据访问类，这些类生成执行 CUID 所需的 SQL 语句。
正如人们所想象的那样，编写生成自定义 SQL 的代码的开发人员很容易犯错误。
我想编写一个生成测试数据(Arrange)的程序，而不是执行 ETL 过程(Act)和验证数据仓库(Assert)。
我认为编写这样的程序并不难。然而，我担心的是，过去我的公司曾尝试做类似的事情，但由于随着新功能的添加对数据库模式进行了许多新更改，导致大量无法维护的单元测试不断失败。
我的计划是编写一个在构建机器上运行的集成测试，而不是任何单元测试来确保 ETL 过程正常运行。测试数据不能完全随机生成，因为业务逻辑决定了数据如何加载到数据仓库。我们有自定义开发工具，可以在数据库定义发生变化时生成新的数据访问类。
我很乐意收到社区的任何反馈，就编写此类易于维护的集成测试给我建议。我的一些想法:
在版本控制(TFS)中保存一个备份的测试数据库，当源或数据仓库发生数据变化时，开发者需要修改备份的数据库。
开发人员需要通过测试程序(在本例中为 C#)手动维护测试数据。该程序将有一个基本框架供开发人员生成他们的测试数据。
当测试数据库初始化时，它会生成随机数据。开发人员将需要编写代码来覆盖某些随机生成的数据，以确保测试通过。
我欢迎任何建议 谢谢
最佳答案
嘿， 虽然我并不真正了解您的 ETL 的整个架构，但我会说，集成测试应该只是您测试过程中的另一个步骤。
即使第一次遇到的单元测试一团糟，您也应该记住，在许多情况下，单个单元测试是检查的最佳位置。或者您想将整个集成测试拆分为三重案例或某事。其他更深层次的，为了保证这三个条件的每一个都正确的流动？
困惑的单元测试只是困惑的生产代码的结果。不要觉得被冒犯。这只是我的意见。单元测试迫使编码人员保持干净的编码风格，并使整个事情更易于维护。
所以...我的目标是，您不仅要考虑对整个事物执行集成测试，因为单元测试(如果以正确的方式使用)可以更详细地关注问题。
问候， MacX
关于c# - 数据库集成测试的可维护性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4825633/