我对整个情况感到非常沮丧，原因如下：
我继承了一个完全未经测试的遗留系统，用于保持许多不同的客户端数据库和一个主数据库（具有不同的模式）同步。该系统在交给我时只是部分完成，有许多缺陷使其无法正常工作约 90% 的时间。
该系统还允许六种不同类型的同步，每种同步不同的（有时是重叠的）表，因为数据库可能相当大，因此客户端可以根据它们的状态优先考虑最重要的表。
我从一些端到端测试开始，使用某些数据在本地设置一个主数据库和几个客户端数据库，然后调用不同的同步方法并验证正确的数据以正确的格式显示在正确的数据库中。
我时间紧迫，由于这个系统至少有一百种不同的方式可以将数据从一个数据库移动到另一个数据库，而且只有几千行代码，我只是不断地进行越来越多的端到端测试，当我接手项目时，基本上每个缺陷存在 1-2 个。我完成了 16 个单元测试（TDD 来自我添加的代码）和 113 个端到端测试，其中许多直接基于先前的缺陷。
我完成了系统，它已经生产了几个月，没有发生任何事故。
最近，我们决定将客户端数据库转换为新数据库，当我使用新数据库运行我的测试（一直在 CI 服务器中每晚运行）时，113 个中的大约 100 个失败。（当然，单元测试都通过了）。
我一直在修复失败的端到端测试，坦率地说，大多数失败是因为一两个简单的原因（比如新的数据库舍入日期不同），但我对我的测试如此脆弱这一事实感到沮丧。虽然他们正确地失败了，但我只需要一两个来告诉我，而不是 100。问题是，没有那么多代码可以进行单元测试，因为大部分只是根据日期从一个表中选择数据，然后从另一个数据库中选择相同的数据，合并两者，然后适当地插入/更新。
如果没有这些测试，我不可能完成这个系统，但维护它们的痛苦基本上是导致我提出这个问题的原因：有什么建议我应该如何进行/或我可以做得更好吗？我第一次编写这些端到端测试是否浪费了太多时间？我读过有效地使用遗留代码工作，但我觉得对于我所感受到的那种痛苦并没有一个很好的答案，除了：“只是重构并编写更多的单元测试”，我觉得这并不是很重要该系统的独特性是很少的代码和大量的数据库转换。