你觉得幸运吗，朋克？

张贴了蒂姆约翰斯,2021年8月31日

340次浏览（过去30天）| 0喜欢| 0评论

我是数学工作的一部分顾问团队基于英国的专门从事软件架构和测试（Andy的我发了一篇文章之前）。作为我最近进行的一些培训的一部分，我在思考这个在内部流传多年的图表：

热闹的，我知道。所提出的观点是一个明显的例子，这让我想 - 如果它是如此明显，写测试是一个好主意，为什么没有更多的人这样做？

你需要一个测试，所以你为什么不写呢？

我想出了一些可能的原因，为什么人们不写测试：

他们不知道怎么做。
他们认为这很困难。
他们认为他们没有时间。
他们还没有被咬——也许他们的代码还不够大/复杂/业务关键，还不足以导致重大停机。

在过去的这些点，你要问自己一个问题：你觉得幸运吗？

一些客户项目我工作的思考，人靠开发的应用程序。如果他们停止工作，他们不会有危险把生命，但10-100s的人可能不能够做他们的工作。这将花费时间和金钱，并有可能为开发应用程序团队声誉受损。我不觉得自己幸运！

自动化测试需要运气了软件交付

我认为这是广泛接受的软件业内人士认为：

软件变得越来越复杂。
我们对它的依赖越来越大。
开发团队规模也在不断扩大。
更频繁地需要更新/交付。

因此，我们需要测试：

验证这种复杂的行为。
确保稳健性。
从整个团队中检查代码在集成时一起工作。

通过自动化快速高效地运行这些测试，我们可以满怀信心地实现频繁交付。

测试帮助各个开发人员

以下是测试在实际项目中帮助我的五种方式：

测试已经让我更改与信心大型项目。我不知道代码到底做了什么，即使在做了很长一段时间之后。当然，我可以给出一个执行摘要，或者我可以告诉你我所做的特定代码的低级细节，但不是中间的所有内容。这是客户工程师的领域知识。通过运行测试，我可以确保所有内容仍然有效作品
测试已经帮我学习新的代码库当我被投入到一个项目中时，他们向我展示了代码的用途以及依赖关系。
测试封装知识作为开发过程的一部分，即使是在一个非常小的项目上，我也获得了设计决策。我反复惊讶于复杂性的增长速度如此之快——在编码的几个小时内，我就忘记了每段代码要做什么以及它所处理的所有边缘情况。
测试允许我着眼于需求，而不是执行细节。这在实现不明显时特别有用。我可以遵循确定它需要做什么的过程，编写（失败的）测试以捕获该信息，执行一些实现，然后迭代–”红色、绿色、重构“。
有帮助驱动软件架构通过创建小型、专注的，可测试成分。如果代码是很难测试，这是几乎可以肯定，因为我已经错了设计它。

测试现在是标准做法

在软件开发的主流，编写测试一直是标准的做法了10多年，。在“小混混”也水涨船高 - 专业的严谨性和工艺是必需的。编写测试与编写代码是齐头并进的。

有人说过（我忘了是谁——也许吧）鲍勃叔叔，也许是我们的许多精彩演讲之一CPP精读），如果你要问在90年代末或21世纪初他们是否使用版本控制的人，你会得到一个不完整的响应 - 这是不常见的地方。今天，如果你不使用版本控制，你会嘲笑！你可能怎么能发展离不开版本控制什么？测试正在经历同样的转变。不要笑话的笑柄！

无论你的团队或客户严格的测试，作为软件行业的专业，你应该向他们展示的方式！

从今天开始写测试

你应该开始编写测试时，你开始一个项目。复杂性构建了令人惊讶的很快，所以从起始处开始测试。这是非常非常容易编写测试，当您去，而不是稍后再回来，并试图做到这一点。

失败了，现在开始！如果您已经有一个没有测试的项目，请不要推迟。您可以通过增量或“修复”方法来构建测试。写作测试不需要是单片事业。随着时间的推移，您的测试套件和覆盖范围将增加。

与此相关的一个常见的问题是如何管理从原型设计算法和工作流程与测试更正式实施的过渡。反对变为“什么是写所有这些测试时，该代码是在这么多通量的点？”。

在这里，需要一个判断电话。在第一阶段，你要回答一些问题，比如“这可能吗”、“我实际上是如何做到的”以及“结果是否值得进一步投资”。在第二个阶段，您开始依赖代码生成的答案，或者其他人也可能希望运行您的代码。无论哪种方式，您都开始构建一个工具。

一旦有第二阶段的提示，就开始测试！

“但我没有时间对任何此类”

许多测试书籍和文章都涵盖了这种共同的反对。引用肯特贝克作为一个例子：

“你感觉的压力越多，你将越少。您的测试越少，您将越多。你的错误越多，你的感受就越多。冲洗并重复“。

- Beck，K。（2003）。测试驱动发展：按示例波士顿：艾迪生·韦斯利

想想那个在开发过程后期出现的bug，它需要几天的时间来追踪。如果你有一个自动测试，在它出现时就可以找到它呢？想想更糟糕的情况——当发现bug时，你已经发布了你的代码。修复这个bug需要多少时间？我可以保证它不会在上午9点发生星期一早上。星期五下午5点试试！