我们刚刚继承了一个新的代码库，它有一堆自动化测试。我们一直在“顺其自然”并在每次合并和部署之前运行它们。我们的一些员工甚至在编写新功能时都会添加测试集。
我一直在努力说服团队，我们需要像热锅一样放弃这些东西，但内部有很多争吵。
正如我所看到的，问题如下 - 这些测试需要很长时间才能运行（在一台开发人员的旧机器上最长可达10分钟！）。他们一直在破碎 - 我不知道你，但我讨厌我的软件坏了。如果我们摆脱所有这些错误代码，我们至少会将错误数量减少10倍。一直在编写新版本的开发人员至少花费两倍的时间来完成其他任务。这太荒谬了，我们已经在紧迫的期限内工作，现在至少在这个项目中，进展正在进一步放缓。我正在查看其中一个开发者提交的一个提交，并且该功能仅超过100个LOC，测试接近250 LOC！
我的问题是我们如何能够删除所有这些错误的，无法保证的代码，每隔五分钟就会中断一次（我不只是想进行搜索和更换，以防实际功能因此而开始破坏）并说服我们的开发人员不要浪费时间吗？
答案 0 :(得分：3)
为什么测试会一直破裂？为什么他们有缺陷且不可维护？这是你问题的根源。
测试应表达您的软件要求。如果它们继续破坏，那可能是因为它们与实现的内部结构紧密耦合，而不是仅通过公共接口调用代码。如果你不能通过公共接口驱动代码，那么这通常表明代码可以更好地设计为更易测试 - 这往往也使它更清晰，更灵活，更健壮。
如果删除测试，那么您将不知道您的代码库是否仍然有效。剥离测试，因为它们是“越野车”会给你带来一个令人不安的问题：如果测试有问题，为什么实际的代码会少一些？
另一方面，如果（遗留）测试的速度非常缓慢和笨拙，那么其中一些至少可能会让它们变得更加麻烦 - 但你必须考虑它们根据具体情况，找出如何更换它们的方法。您可以对测试进行计时，看看是否有任何特别慢的目标 - 如果它们是JUnit测试，那么您将自动获得计时。您还可以测量代码覆盖率并查看测试是否重叠，或者考虑到它们的大小和运行时覆盖非常少量的代码库。在处理遗留代码的主题上有一些books。
如果操作正确，自动化测试可以加快开发速度，而不是减慢速度（假设您希望软件实际工作），因为开发人员可以进行更改并重构代码，而不必担心每次触摸任何内容时都会破坏其他内容，并且因为他们可以清楚地分辨出某个功能何时起作用，而不是“它似乎有效，我认为”。
加快测试是可取的。如果他们在端到端地运行系统，并不是所有的测试都可以很快，但我通常将这些“特征测试”与细粒度单元测试分开，这些测试应该非常快，因此它们可以一直运行。请参阅Michael Feathers的this posting关于单元测试的定义，以及如何处理慢速测试。
如果您关心代码是否有效，那么测试代码与实际代码一样重要 - 它需要正确，清晰并考虑因素以避免重复。拥有至少与真实代码一样多的测试代码是完全正常的，尽管比率将随代码类型而变化很大。如果没有看到它，你的具体例子是否过分是不可能的。
更新：在您的other questions之一中，您说“我介绍了最新的spiffy框架，单元和功能测试，CI，错误跟踪器和敏捷工作流程对环境“。您是否改变了对测试的看法，或者这个问题是否也是一个稻草人？或者你的问题是否真的“我应该放弃所有旧测试并重新开始”吗？ （考虑到你对开发人员编写新测试的评论，它不是这样读的。）
答案 1 :(得分：0)
测试是测试框架的一部分，还是他们自己生成的测试逻辑，它们已经附加到您的生产逻辑上？
如果是本土的，您可能会有一些运气说服团队将测试重构为结构化框架。现在有很多东西，这可能不是第一次建立时的情况。
如您所知，越早捕获并修复错误越多越好。自动化测试是人们在仍然易于修复时捕获错误的一种方式。这可能会花费你额外的开发时间来准备和维护测试，但要平衡除了最终客户之外的所有人都会遇到的重大缺陷（特别是在涉及截止日期时）。