我们刚刚继承了一个包含大量自动化测试的新代码库。我们一直在“顺其自然”并在每次合并和部署之前运行它们。我们的一些员工甚至在编写新功能时添加到测试集合中。
我一直在尽我最大的努力说服团队我们需要像烫手山芋一样放弃这些东西，但内部存在很多争吵。
正如我所看到的，问题如下 - 这些测试需要很长时间才能运行（在一位开发人员的旧机器上最多需要 10 分钟！）。他们一直在崩溃——我不了解你，但当我的软件崩溃时我讨厌它。如果我们只是摆脱所有这些有缺陷的代码，我们至少会将错误数量减少 10 倍。一直在编写新代码的开发人员在做任何事情上花费的时间至少是其他人的两倍。这太荒谬了，我们已经在紧迫的期限内工作，现在进展进一步放缓，至少对于这个项目来说。我正在查看其中一位开发人员所做的提交，该功能刚刚超过 100 LOC，测试接近 250 LOC！
我的问题是我们如何去除所有这些错误的、无法维护的、每五分钟中断一次的代码（我不只是想进行搜索和替换，以防实际功能因此而开始中断）并说服我们的开发人员别浪费时间了？
为什么测试总是失败？为什么它们有缺陷且无法维护？那是你问题的根源。
测试应该表达你的软件的需求。如果它们不断中断，那可能是因为它们与实现的内部耦合太紧密，而不是仅通过公共接口调用代码。如果您不能通过公共接口驱动代码，那么这通常表明代码可以更好地设计为更具可测试性——这也往往会使代码更清晰、更灵活和更健壮。
如果您删除测试，那么您将不知道您的代码库是否仍然有效。因为测试有“bug”而去掉测试会给你带来一个不舒服的问题：如果测试有 bug，为什么实际代码的 bug 会少一些？
另一方面，如果（旧版）测试非常缓慢且笨拙，那么其中一些至少可能会比它们更有价值 - 但您必须逐案考虑它们，并且弄清楚你将如何更换它们。您可以对测试进行计时，看看是否有任何特别慢的要针对 - 如果它们是 JUnit 测试，那么您会自动获得计时。您还可以测量代码覆盖率并查看测试是否重叠，或者考虑到它们的大小和运行时间，它们是否覆盖了非常少量的代码库。有一些专门针对处理遗留代码的书籍。
如果做得好，自动化测试会加快开发速度，而不是减慢开发速度（假设您希望软件实际运行），因为开发人员可以进行更改和重构代码，而不必担心每次接触任何东西都会破坏其他东西，并且因为他们可以清楚地判断某个功能何时起作用，而不是“我认为它似乎起作用”。
加快测试速度是可取的。如果端到端地运行系统，并非所有测试都可以很快，但我通常将此类“功能测试”与细粒度的单元测试分开，后者应该运行得非常快，因此它们可以一直运行。请参阅Michael Feathers 的这篇文章，了解他对单元测试的定义，以及如何处理慢速测试。
如果您关心您的代码是否有效，那么测试代码与实际代码一样重要——它需要正确、清晰和分解以避免重复。测试代码至少与真实代码一样多是完全正常的，尽管比率会因代码类型而有很大差异。你的具体例子是否过分，不看就无法判断。
更新：在您的其他问题之一中，您说“我已经向环境介绍了最新的漂亮框架、单元和功能测试、CI、错误跟踪器和敏捷工作流”。您是否改变了对测试的想法，或者这个问题可能是稻草人？还是您的问题真的是“我应该放弃所有旧测试并重新开始”？（鉴于您对开发人员编写新测试的评论，它不是这样读的......）
测试是测试框架的一部分，还是它们自己开发的测试逻辑部分已经附加到您的生产逻辑？
如果是本土开发的，您可能会很幸运地说服团队将测试重构为结构化框架。现在有很多，这在最初设置时可能不是这种情况。
如您所知，越早发现并修复错误越好。自动化测试是人们在错误仍然很容易修复时发现错误的一种方式。准备和维护测试可能会花费您额外的开发时间，但要平衡这一点与除了最终客户之外的每个人都漏掉的主要缺陷（尤其是在涉及截止日期时）。