程序员不测试代码的9个借口

我们都可以涉及的借口清单

程序员不测试代码的9个借口

> Photo by Fabian Grohs on Unsplash

程序员和测试-绝对不是天堂。 尽管大多数程序员都了解测试的重要性及其用途,但有时我们只是不喜欢它。

为了避免发生一件事,有很多借口一直被利用:编写测试。

您是否曾经使用此列表中的任何借口?

9."这段代码太小了……它什么都不会破坏"

每个开发人员都编写了很小的代码,以至于无法破坏任何重大的东西。 但是,它仍然设法破坏了某些东西。 您添加的两行代码成功打破了您无法预料的内容。

您怎么知道您的代码完美地工作?

请让您的话语得到一些实际测试的支持。 全面的测试可以过滤出关键的错误,确保代码按预期的方式工作。

8."客户只想为可交付成果付费"

每个客户都希望看到尽可能多的可交付成果,因为这使他们感到开发团队正在做一些实际工作。 他们希望尽可能地降低成本。

这正是开发人员在不希望进行测试时告诉其经理的内容。

测试是软件开发的重要组成部分,而这部分代码与任何其他代码一样重要—因此,您应该将其视为这样。 在编写的估算中包括编写测试的时间。

从长远来看,编写测试可降低维护成本并降低开发成本。

7."如果手动进行测试,可以更快地进行测试"

手动测试的问题是您必须一遍又一遍地进行测试。 然后再次。

是的,一次手动执行某个功能可能会更快。 但是,当您必须一遍又一遍地进行手动测试时,这非常耗时。 手动测试是无止境的,而且非常昂贵。

编写测试会花费一些时间,但是一旦获得测试,就可以无限次地运行它,并且与手动测试相比,它只花费很少的时间。 与打开浏览器并输入页面地址相比,运行自动化测试所需的时间更少。

6."这段代码不变"

"测试代码没有任何变化是没有意义的。 那完全是浪费时间。"

好吧,我们在软件开发中唯一可以确定的就是需求将会改变。 有时它们似乎在不断变化。

人们出于多种原因改变主意,并且定期这样做。 需求变化可能是由许多原因引起的。 有些人要求功能,但是他们实际上并不知道他们想要什么。 不幸的是,这种情况经常发生。 需求可能发生变化的另一个原因是由于组织内部的政治因素。

每当您处理不断变化的需求时,都应该优先测试最常见的流程。

5."需求不好"

不好的要需求不是跳过编写测试的借口。 您有很多选择可以找出要求。 有时情况会变得更糟。 令人遗憾的是,未记录的要求是我们大多数人面临的比预期更多的现实。

在这两种情况下,您都需要处理任何少量的文档。 尝试浏览旧的电子邮件或您做过的一些笔记,以寻找一些线索。

您还想了解一下该应用程序的当前版本或较旧版本-当然可以。 您可能会在这里找到很多隐藏的线索。 别忘了看一下测试。 它们可能充满了可以帮助您的隐藏宝石。

最后但并非最不重要的一点是,尝试与一些团队成员交谈。 他们可能对您要查找的未记录的要求了解更多。 想一想在您无法参加的会议中讨论但未记录的一件事。

4."测试增加了开发时间,而我们用光了时间"

当涉及到测试时,这是最大的误解之一。 每当您第一次开始编写测试时,都肯定会增加开发时间。 首先,您需要学习如何编写可测试的代码以及如何进行适当的测试。 从长远来看,这是一项投资。

一旦测试成为一种习惯,它将为您节省大量时间。 和头痛。 进行测试将为您解决开发人员缺乏部署代码的信心的问题-尽管事实上您能够轻松地单击按钮来运行整个测试套件。

3."我不知道要测试什么"

您对要测试的内容有疑问吗? 全部测试!

一个好的开始就是测试所有可能的最常见的情况。 这将告诉您何时该部分代码中断,影响最大。

但是,除了点击"幸福道路"场景之外,还需要进行更多测试。 您应该测试最复杂的部分代码或最有可能出错的代码片段的极端情况。

每当发现错误时,编写覆盖该测试用例的新测试都被视为一种很好的做法。

将编写测试作为日常工作的一部分-不要使其成为可选项目。

2."这段代码不可测试"

您的意思是您真的不知道如何测试该段代码。 可能是因为您的代码结构不好,因此无法测试。 如果只是一小段代码,请将其重构为可测试的小段。

当您处理的代码设计不佳且代码次优时,确实无法测试时,您会遇到一些更大的问题。 无法测试的代码维护和修改成本很高。 最重要的是,新团队成员很难学习无法测试的代码。

如果您不测试代码,则最终会遇到开发人员缺乏部署代码信心的问题。 缺乏测试使他们感到焦虑,因为他们没有确认自己所做的更改不会破坏任何东西。

1."我的代码可以正常工作-为什么还要费心测试它?"

这种声明通常由自大的开发人员做出。 充其量,认为一个人可以编写完美的代码是幼稚的。 即使是最优秀的程序员也会犯错。 他们一直都在制造它们。

没有人是完美的-错误发生的频率比应该发生的频率高,这是完全可以的,因为我们可以从这些错误中吸取教训。

对您的代码充满信心是可以的。 但是,即使其他开发人员审核了您的代码并批准了该代码,您也不应该…… 即使您已经手动测试了一些用例。 所有这些事情仍然存在危险。

所有这些都取决于人为因素。 这正是您不想要的,因为人为因素有时会失败。 发生这种情况时,您需要进行适当的测试。

"除了我,没有人真正在第一时间创建完美的代码。 但是我只有一个。"

莱纳斯·托瓦尔兹


总结

您能谈谈这份清单上的任何借口吗?

我想我们以前都使用过其中一种。 下次,我们可能应该考虑编写测试,因为我们都知道不测试我们的代码会在以后的某个时刻再次引起我们的注意。

谢谢阅读!

(本文翻译自Daan的文章《9 Excuses Why Programmers Don't Test Their Code》,参考:
https://medium.com/better-programming/9-excuses-why-programmers-dont-test-their-code-8860a616b1b5)


分享到:


相關文章: