测试优化

Question

我们刚刚继承了一个包含大量自动化测试的新代码库。我们一直在“顺其自然”并在每次合并和部署之前运行它们。我们的一些员工在编写新功能时甚至会添加到测试集合中。

我一直在尽我最大的努力说服团队我们需要像烫手山芋一样放弃这些东西，但内部存在很多争吵。

在我看来，问题如下 - 这些测试需要很长时间才能运行（在一位开发人员的旧机器上最多需要 10 分钟！）。他们一直在崩溃——我不了解你，但当我的软件崩溃时我讨厌它。如果我们只是摆脱所有这些有缺陷的代码，我们至少会将错误数量减少 10 倍。一直在编写新代码的开发人员在做任何事情上花费的时间至少是其他人的两倍。这太荒谬了，我们已经在紧迫的期限内工作，现在进展进一步放缓，至少对于这个项目来说。我正在查看其中一位开发人员所做的提交，该功能刚刚超过 100 LOC，测试接近 250 LOC！

我的问题是我们如何去除所有这些错误的、无法维护的、每五分钟中断一次的代码（我不只是想进行搜索和替换，以防实际功能因此而开始中断）并说服我们的开发人员不要再浪费时间了？

Answer 1

为什么测试总是失败？为什么它们有缺陷且无法维护？这就是你问题的根源。

测试应该表达您的软件的要求。如果它们不断中断，那可能是因为它们与实现的内部耦合过于紧密，而不是仅通过公共接口调用代码。如果您不能通过公共接口驱动代码，那么这通常表明代码可以更好地设计为更可测试 - 这也往往会使代码更清晰、更灵活和健壮。

如果您删除测试，那么您将不知道您的代码库是否仍然有效。因为测试有“bug”而去掉测试会给你带来一个不舒服的问题：如果测试有 bug，为什么实际代码的 bug 更少？

另一方面，如果（旧版）测试非常缓慢且笨拙，那么 其中一些至少可能会比它们更有价值 - 但你必须考虑它们根据具体情况，确定如何更换它们。您可以为测试计时，看看是否有任何特别慢的目标 - 如果它们是 JUnit 测试，那么您会自动获得计时。您还可以测量代码覆盖率并查看测试是否重叠，或者考虑到它们的大小和运行时间，它们是否覆盖了非常少量的代码库。有一些 books 专门针对处理遗留代码的主题。

如果做得好，自动化测试会加快开发速度，而不是减慢开发速度（假设您希望软件能够真正运行），因为开发人员可以进行更改和重构代码，而不必担心每次接触任何东西都会破坏其他东西，并且因为他们可以清楚地判断某个功能何时起作用，而不是“我认为它似乎起作用”。

加快测试速度是可取的。如果端到端运行系统，并非所有测试都可以很快，但我通常将此类“功能测试”与细粒度单元测试分开，这些单元测试应该运行得非常快，因此它们可以一直运行。请参阅 Michael Feathers 的this posting，了解他对单元测试的定义，以及如何处理慢速测试。

如果您关心您的代码是否有效，那么测试代码与实际代码一样重要 - 它需要正确、清晰且经过分解以避免重复。拥有至少与真实代码一样多的测试代码是完全正常的，尽管比率会随着代码类型的不同而有很大差异。你的具体例子是否过分，不看就说不准。

更新：在你的 other questions 中你说 “我已经向环境中引入了最新的漂亮框架、单元和功能测试、CI、错误跟踪器和敏捷工作流"。您是否改变了对测试的想法，或者这个问题可能是稻草人？还是您的问题真的是“我应该放弃所有旧测试并重新开始”？ （考虑到您的 cmets 关于开发人员编写新测试的内容，它不是这样读的……）

Answer 2

测试是测试框架的一部分，还是它们自己开发的测试逻辑部分已经附加到您的生产逻辑？

如果是本地开发的，您可能会很幸运地说服团队将测试重构为结构化框架。现在有很多东西，最初设置时可能不是这种情况。

如您所知，越早发现并修复错误越好。自动化测试是人们在仍然容易修复时发现错误的一种方式。准备和维护测试可能会花费您额外的开发时间，但要平衡这一点与除了最终客户之外的所有人都漏掉的重大缺陷（尤其是在涉及截止日期时）。