我对这种情况感到非常感到沮丧，这就是为什么：
我继承了一个完全未经测试的遗留系统，用于保持许多不同的客户端数据库和一个主数据库（具有不同的模式）同步。该系统仅在给予我时才部分完成，有许多缺陷阻止它在90％的时间内正常工作。
该系统还允许六种不同类型的同步，每种同步不同（有时重叠）表，因为数据库可能相当大，因此客户端可以根据其状态优先考虑最重要的表。
我从一些端到端测试开始，在本地使用某些数据设置主数据库和多个客户端数据库，然后调用不同的同步方法，并以正确的格式验证正确数据中出现的正确数据。 / p>
我时间紧迫，因为这个系统至少有一百种不同的方式，数据可以从一个数据库移动到另一个数据库，而且只有几千行代码，我只是不断地做出越来越多的结束 - 最终测试，当我接手项目时，每个缺陷基本上1-2个。我完成了16个单元测试系统（我添加的代码中的TDD）和113个端到端测试，其中许多直接基于先前的缺陷。
我完成了系统，它已经生产了几个月没有发生任何事故。
最近，我们决定将客户端数据库转换为新数据库，当我使用新数据库运行我的测试（一直在CI服务器中每晚运行）时，113个中的大约100个失败。 （当然，单位测试全部通过。）
我一直在修复失败的端到端测试，坦率地说，大多数失败是出于一两个简单的原因（比如新的数据库舍入日期不同）但我对我的测试如此脆弱这一事实感到沮丧。虽然他们正确地失败了，但我只需要一两个告诉我，而不是100。问题是，单元测试没有那么多代码，因为大多数代码只是从一个表中选择数据日期，然后从另一个数据库中选择相同的数据，合并这两个数据，然后适当地插入/更新。
没有这些测试，我无法完成这个系统，但是维护它们的痛苦基本上是导致我这个问题的原因：任何建议我应该如何继续/或者我可以做得更好？ 我第一次浪费了太多时间编写这些端到端测试吗？我读到了与遗产有效合作 代码，但我觉得那里没有真正的好答案，除了：“只是重构并编写更多的单元测试”，我认为这对于独特的选择并不是一个很好的选择。这个系统的本质是很少的代码和很多数据库转换。
答案 0 :(得分：4)
您可以创建数据库代理类，确保它们是与真实数据库通信的唯一类。使用 dependency-injection 对所有逻辑代码进行单元测试，而无需与实际数据库进行通信。创建尽可能少的端到端测试，以确保代理可以正确读/写数据库。
端到端测试通常很脆弱。因此，尽可能少地创建它们，如果您需要创建很多，您可以创建一个抽象层来设置fixture和断言。 测试用例中的重复与代码中的重复一样难以维护。
有效地使用旧版代码是一个良好的开端，我建议 xUnit测试模式，它基本上是单元测试的圣经，包含很多好的建议，包括一节用数据库测试。
编辑： TDD就是隔离逻辑。我的意思是控制流语句，正则表达式，算法，数学，应该在您的代理之外，您可以轻松地对它们进行单元测试。你有113次测试，这让我怀疑有逻辑可以提取和单元测试。
如果要创建SQL命令，可以使用Builder模式验证命令是否正确创建，如果需要更改SQL方言，则只有一个位置可以进行更改。
使您的代码可测试可能意味着您需要进行一些积极的重构。根据项目的重要性和长寿性，困难的部分将决定它的价值。