端对端测试太多？ [关闭]

Question

我真的对整个情况感到沮丧，原因如下：

我继承了一个完全未经测试的遗留系统，用于保持许多不同的客户端数据库和一个主数据库（具有不同的架构）同步。该系统在交给我时只完成了部分工作，存在许多缺陷，导致它在大约 90% 的时间里无法正常工作。

该系统还允许六种不同类型的同步，每种同步不同的（有时是重叠的）表，因为数据库可能相当大，因此客户端可以根据状态优先考虑最重要的表。

我从一些端到端测试开始，使用某些数据在本地设置一个主数据库和几个客户端数据库，然后调用不同的同步方法并验证正确的数据以正确的格式显示在正确的数据库中。

我时间紧迫，因为这个系统至少有一百种不同的方式可以让数据从一个数据库移动到另一个数据库，而且只有几千行代码，我只是不断地制作越来越多的端到端-最终测试，基本上是我接手项目时存在的每个缺陷 1-2 个。我用 16 个单元测试（根据我添加的代码进行 TDD）和 113 个端到端测试完成了系统，其中许多测试直接基于先前的缺陷。

我完成了这个系统，它已经在生产中几个月了，没有发生任何事故。

最近，我们决定将客户端数据库转换为新数据库，当我使用新数据库运行我的测试（一直在 CI 服务器中每晚运行）时，113 个中大约有 100 个失败。 （当然，单元测试都通过了）。

我一直在修复失败的端到端测试，坦率地说，大多数失败的原因只是一两个简单的原因，（比如新的数据库舍入日期不同），但我对我的测试如此脆弱这一事实感到沮丧.虽然他们正确地失败了，但我只需要一两个来告诉我，而不是 100。问题是，没有那么多代码可以进行单元测试，因为大部分代码只是从一个表中选择数据日期，然后从另一个数据库中选择相同的数据，将两者合并，然后适当地插入/更新。

如果没有这些测试，我不可能完成这个系统，但是维护它们的痛苦基本上是导致我提出这个问题的原因：有什么建议我应该如何进行/或我可以做得更好吗？ 我第一次编写这些端到端测试是否浪费了太多时间？我读过有效地处理遗产 代码，但我觉得对于我所感受到的那种痛苦，那里并没有一个很好的答案，除了：“只是重构并编写更多的单元测试”，我觉得这对于独特的人来说并不是一个真正的选择这个系统的本质是很少的代码和大量的数据库转换。

Answer 1

您可以创建数据库代理类，确保它们是唯一与真实数据库对话的类。使用 dependency-injection 对所有逻辑代码进行单元测试，而无需与实际数据库对话。创建尽可能少的端到端测试以确保代理可以正确读取/写入数据库。

端到端测试本质上通常很脆弱。所以尽可能少地创建它们，如果你需要创建很多，你可以创建一个抽象层来设置固定装置和断言。 测试用例中的重复与代码中的重复一样难以维护。

有效地使用遗留代码是一个好的开始，我推荐 xUnit 测试模式，它基本上是单元测试的圣经，其中包含很多好的建议，包括一节使用数据库进行测试。

编辑： TDD 是关于隔离逻辑的。我的意思是控制流语句、正则表达式、算法、数学，应该在您的代理之外，您可以轻松地对它们进行单元测试。你有 113 个测试，这让我怀疑存在可以提取和单元测试的逻辑。

如果您正在创建 SQL 命令，您可以使用Builder 模式来验证命令是否正确创建，如果您需要更改 SQL 方言，则只有一个地方可以进行更改。

使您的代码可测试可能意味着您需要进行一些积极的重构。困难的部分将是根据项目的重要性和寿命确定价值多少。