为什么开发人员不编写更多测试？

我经常在会议上谈论 测试微服务，我问与会者的第一个问题是他们是否编写测试。房间通常在为他们的代码编写测试的开发人员和不为他们的代码编写测试的开发人员之间分配 50-50。当我在编码训练营做客座讲座时，这种差异变得更加明显，我发现只有不到十分之一的毕业生真正知道如何编写单元测试。

我的轶事观察也得到了调查的支持。Diffblue 发现 42% 的开发人员跳过编写测试，而 Stack Overflow 发现 37% 的开发人员不为他们的工作代码编写测试。

为了理解为什么开发人员没有更好地编写测试，我决定向几个运行软件团队的朋友提出这个问题。在这篇文章中，我收集了他们的一些观察(与我自己的混合)，关于为什么开发人员没有像您认为的那样经常编写测试。他们的一些回答让我感到惊讶，尤其是当我们谈到今天测试的局限性时。

最后，我请他们每个人给我一些提示，给那些可能不熟悉自动化测试的工程领导者和开发人员。如果你是今天跳过测试的大约 40% 的开发人员之一，我希望他们的建议能鼓励你开始。

反对测试

从广义上讲，自动化测试倾向于提高软件的可靠性、质量和可维护性。

“如果你对某个功能进行了测试，那么你就会知道未来的一些变化是否会破坏某些东西，” Earthly 的Adam Gordon Bell 告诉我。他补充说，测试是一种动态的文档形式：“很多时候，阅读测试比阅读实际实现更容易理解某些东西的作用。”

也就是说，编写测试需要时间，许多开发人员没有(或不能)抽出时间来编写它们。随着代码库的增长和测试覆盖率的不断下降，这个问题变得更加明显。

管理经常推出大量功能，而测试总是从优先级列表中下滑……一旦您拥有足够大的代码库，您就可以花费无限量的时间来编写测试，因此可能会令人生畏且难以知道从哪里开始。

如果截止日期很紧或者团队领导者不是特别致力于测试，这通常是软件开发人员被迫跳过的第一件事。

另一方面，一些开发人员只是认为测试不值得他们花时间。“他们可能会想，‘这是一个非常小的功能，任何人都可以为此创建一个测试，我的时间应该在更重要的东西利用。’”的Mudit辛格 LambdaTest告诉我的。

我已经看到这种测试态度在企业环境中“低于”开发人员，在这些环境中，专门的 QA 团队可能负责大部分测试，但它可能发生在任何地方。我曾经在一家初创公司管理过一位高级开发人员，他鼓励我雇佣初级开发人员来为他编写测试。

测试权衡和限制

所以，你可能认为答案很简单。给开发人员更多时间来编写测试并使其成为他们工作的一部分，对吗?

事实上，自动化测试存在一些合理的限制。像软件开发中的许多复杂问题一样，选择测试与否是关于了解权衡。

“写自动化测试可以提供信心，您的应用程序工作的某些部分如预期，”首席执行官艾丹Cunniff， 光纤告诉我，“但代价是你已经投入了大量的时间‘稳定’，使‘可靠’你系统的那部分。”

我在创业公司的经历中也看到了这一点。我曾经花了三个星期来构建一个新功能、编写测试和解决代码审查，结果却被告知业务团队改变了主意，该功能将在下一个 sprint 中删除。

虽然测试可能使我的新功能更好、更易于维护，但从技术上讲，它们对业务来说是浪费时间，因为该功能并不是我们真正需要的。在开始编写代码之前，我们没有投入足够的时间来理解问题并制定计划。

“想象一下，一群建筑工人和建筑师在一块空地上与客户和一大堆木材会面。然后以自发的方式建造房屋。当客户怀疑地看着完工的房子并抱怨屋顶看起来不太安全时，承包商回答说“别担心，我们会等到下雨然后修补漏水的地方。”......没有其他专业建造质量不受控制的产品然后依靠测试(和缺陷修复)来提高产品质量。

最后，某些形式的测试特别难以实现，因为它们要求您的代码以特定方式编写。这是对单元测试的常见抱怨。

一方面，单元测试迫使开发人员以一种“可测试”的方式构建他们的代码，但另一方面，这些单元测试很少告诉你最终的应用程序是否为用户提供了价值。

在大多数企业中，唯一具有业务价值的测试是源自业务需求的测试。大多数单元测试源自程序员对函数应该如何工作的幻想……那些没有可证明的价值。

如果您在开始之前没有单元测试覆盖率的遗留代码库中工作，则几乎不可能追溯添加它们。因此，大多数开发人员转向集成或端到端测试。

这些功能测试可能会有所帮助，但它们也存在问题。任何重要的应用程序都会有几十个功能和逻辑分支，因此几乎不可能跟上所有预期的行为。正如 JB Rainsberger 在他的文章Integrated Tests Are A Scam 中指出的那样 ，一个有 20 个页面的中型 Web 应用程序可能需要 10,000 到 1,000,000 次测试才能涵盖所有用户故事。

那么为什么还要尝试呢?

我认为单元测试和特别是测试驱动的开发被其支持者过度宣传为解决所有问题的方法……但是测试，如果做得好，是非常有价值的。为未来的编写测试，他们将试图了解这个方法在未来的作用。让自己有信心做出需要做出的改变。

虽然测试不是灵丹妙药，但当它适当地应用于手头的软件时，它是合法有用的。几乎在所有情况下，测试对开发人员来说都是积极的，即使它有局限性。开发团队要做的重要事情是有意识地了解他们测试的方式和内容。

Aidan Cunniffe 告诉我：“仔细考虑将测试工作投入到哪里是平衡投资与其提供的价值的最佳方式。” 跳过对新功能的第一个 alpha 版本的测试可能是合理的，但是“当该功能成为其他 3 个功能的支柱时，就该开始测试了。”

就我个人而言，我认为混合方法是最好的。单元测试对于快速覆盖大量微小案例很有用，集成测试确保各个部分按预期进行交互，端到端测试提供用户界面是否正常工作的最终检查。

还出现了新的测试品种，试图减轻我们许多人采用的分层测试方法的一些缺点。例如，我 去年调查了一些低代码测试工具，而且还有更多。RelicX首席执行官 Sushil Kumar 指出，“使用基于 AI/ML 的测试自动生成测试脚本可以大大减轻开发人员的负担。”

入门

如果您对辩论如此深入，并且您只是因为不确定从哪里开始而没有进行测试，那么让我们谈谈您可以从哪里开始。

最容易开始的地方通常是单元测试。Speedscale 的 Ken Ahrens 告诉我：“当你刚开始测试时，弄清楚你的团队使用什么单元测试框架，并为你的第一次代码签入包含一个单元测试用例。” 继续解释从小做起，但让测试成为一种习惯是坚持下去的关键。

接下来，您需要获得团队其他成员和领导层的支持。需要给开发人员时间来编写测试，并了解这项投资从长远来看会得到回报。

团队中的每个人都在编写测试，或者没有人在编写测试，这确实是一种文化实践，一种技术僵局。没有人想成为唯一这样做的人。

证明测试价值的一种方法是使用它们来防止回归。“如果某些东西不起作用，”Adam Gordon Bell 告诉我，“在修复它之前，先编写一个功能正确的测试。” 这将降低未来回归的可能性，并让您的团队在将来更新该部分代码时充满信心。

测试有局限性，它们不能替代出色的系统设计，但测试在软件开发中也占有一席之地。给工程师时间进行测试并将测试的价值传授给您的团队是工程领导力的一个重要角色，而且随着软件变得越来越复杂，它只会变得越来越重要。