文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

在我的一次单元测试课程中,我们讨论了一个感觉已经被讨论了无数次的话题。

那个团队问我的问题是:“你怎样去说服你的客户为单元测试买单?”

因为它会为项目增加差不多20%的预算,对不?

虽然我们还可以讨论这个数字的有效性, 但真正有意思的是隐藏在其背后的问题,也就是关于“单元测试带来的增加成本”。

它是一个附加品!

想象一下,你去会见一个客户,并说“我们可以让项目更便宜些,只是我们需要跳过设计的部分”。这听起来专业吗?会有客户能够接受一个都没有经过某种形式设计的系统吗?

第 1 段(可获 1.49 积分)

即使是当客户只是想要个概念验证(POC)或者愿意接受一个质量不怎么高的系统,他们也希望我们会先设计一下。如果我们给他们提供的是没有经过深思熟虑的东西,那么他们肯定会认为我们不够专业。

我们不会将设计作为项目里一个单独的修补性的部分来谈论,因为我们认为它是我们工作的一部分。

但是,单元测试呢?当然,我们可以因为合适的价格增加或者去掉它。

它并不是什么“产品代码” ,甚至都不会被交付。它是人们在开会时听到的一个新事物,但是却使得生活在真实世界的开发者们更加艰难。

第 2 段(可获 1.35 积分)

不管借口是什么,它已经成为项目计划中的一个单项。

如果我们继续将单元测试作为一个附加的编码工作来讨论的话,那就很容易知道我们是如何经常讨论这个话题的。

够了够了!

单元测试是开发过程中的一个组成部分。它不是你为达到最后期限而应该放弃的东西。它是项目的一部分,也是正常开发工作的一部分。它跟编写代码、设计、测试、编写文档以及项目中的其他任意部分一样。

编写代码(有时是糟糕,复杂的代码)是工作的一部分。它有自己的成本(编写,维护,审阅,修复)。它也有自己的价值(能够正常工作)。

那么,猜猜怎么着。单元测试也是一样的。它是我们为了生产出能工作的软件的众多事情中的一件。

单元测试只是工作的一部分。

第 3 段(可获 1.74 积分)

文章评论