太多的端到端测试？

Question

我对这整个情况感到非常沮丧,原因如下:

我继承了一个完全未经测试的遗留系统,用于保持许多不同的客户端数据库和一个主数据库(具有不同的模式)同步.该系统仅在给我时完成,有许多缺陷阻止它在90%的时间内正常工作.

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

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

我被迫按时,由于这个系统至少有一百种不同的方式,数据可以从一个数据库移动到另一个数据库,只有几千行代码,我只是不断进行越来越多的端到端测试,当我接手项目时,每个缺陷基本上1-2个.我完成了16个单元测试系统(我添加的代码中的TDD)和113个端到端测试,其中许多直接基于先前的缺陷.

我完成了系统,它已经生产了几个月没有发生任何事故.

最近,我们决定将客户端数据库转换为新数据库,当我使用新数据库运行我的测试(一直在CI服务器中每晚运行)时,113个中的大约100个失败.(当然,单位测试全部通过).

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

没有这些测试,我无法完成这个系统,但维护它们的痛苦基本上是导致我这个问题的原因:任何建议我应该如何进行/或者我可以做得更好？我第一次浪费了太多时间编写这些端到端测试吗？我读过有效使用遗留代码的工作,但我觉得那里没有真正的好答案,除了:"只是重构并编写更多的单元测试",我感觉并不是真的很好一个选项是这个系统的独特性质,只需很少的代码和大量的数据库转换.

Answer 1

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

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

有效地使用遗留代码是一个好的开始，我推荐xUnit Test Patterns，它基本上是单元测试的圣经，提供了很多好的建议，包括关于数据库测试的部分。

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

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

让您的代码可测试可能意味着您需要积极地进行重构。困难的部分是根据项目的重要性和寿命来确定值得多少钱。