关闭。这个问题是off-topic .它目前不接受答案。
想改进这个问题？ Update the question所以它是on-topic对于堆栈溢出。
10年前关闭。
Improve this question
我是真的对整个情况感到沮丧，原因如下:
我继承了一个完全未经测试的遗留系统，用于保持许多不同的客户端数据库和一个主数据库(具有不同的模式)同步。该系统在交给我时只是部分完成，有许多缺陷使其无法正常工作约 90% 的时间。
该系统还允许六种不同类型的同步，每种同步不同的(有时是重叠的)表，因为数据库可能相当大，因此客户端可以根据它们的状态优先考虑最重要的表。
我从一些端到端测试开始，使用某些数据在本地设置一个主数据库和几个客户端数据库，然后调用不同的同步方法并验证正确的数据以正确的格式显示在正确的数据库中。
我时间紧迫，由于这个系统至少有一百种不同的方式可以将数据从一个数据库移动到另一个数据库，而且只有几千行代码，我只是不断地进行越来越多的端到端测试，当我接手项目时，基本上每个缺陷存在 1-2 个。我完成了 16 个单元测试(TDD 来自我添加的代码)和 113 个端到端测试，其中许多直接基于先前的缺陷。
我完成了系统，它已经生产了几个月，没有发生任何事故。
最近，我们决定将客户端数据库转换为新数据库，当我使用新数据库运行我的测试(一直在 CI 服务器中每晚运行)时，113 个中的大约 100 个失败。 (当然，单元测试都通过了)。
我一直在修复失败的端到端测试，坦率地说，大多数失败是因为一两个简单的原因(比如新的数据库舍入日期不同)，但我对我的测试如此脆弱这一事实感到沮丧。虽然他们正确地失败了，但我只需要一两个来告诉我，而不是 100。问题是，单元测试的代码并不多，因为大部分只是根据日期从一个表中选择数据，然后从另一个数据库中选择相同的数据 ，合并两者，然后适本地插入/更新。
如果没有这些测试，我不可能完成这个系统，但是维护它们的痛苦基本上是导致我提出这个问题的原因:有什么建议我应该如何进行/或我可以做得更好吗？ 我第一次编写这些端到端测试是否浪费了太多时间？我读过有效地处理遗产
代码，但我觉得对于我所感受到的那种痛苦并没有一个很好的答案，除了:“只是重构并编写更多的单元测试”，我觉得这对于独特的人来说并不是一个真正的选择这个系统的本质是很少的代码和大量的数据库转换。
最佳答案
您可以创建数据库代理 类，确保它们是唯一与真实数据库对话的类。使用依赖注入(inject) 在不与实际数据库对话的情况下对所有逻辑代码进行单元测试。创建为 尽可能少的端到端测试确保代理可以正确读取/写入数据库。
端到端测试本质上通常是脆弱的 .所以尽可能少地创建它们，如果你需要创建很多，你可以创建一个抽象层来设置固定装置和断言。 测试用例中的重复 就像代码中的重复一样难以维护。
有效地使用遗留代码是一个好的开始，我推荐 xUnit 测试模式，它基本上是单元测试的圣经，有很多好的建议，包括关于数据库测试的部分。
编辑: TDD 是关于隔离逻辑的。我的意思是控制流语句、正则表达式、算法、数学，应该在您的代理之外，您可以轻松地对它们进行单元测试。你有 113 个测试，这让我怀疑存在可以提取和单元测试的逻辑。
如果要创建 SQL 命令，可以使用 Builder模式来验证命令是否正确创建，如果您需要更改 SQL 方言，则只有一个地方可以进行更改。
使您的代码可测试可能意味着您需要进行一些积极的重构。困难的部分将是根据项目的重要性和生命周期来确定它的值(value)。
关于unit-testing - 端对端测试太多？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9199458/