“单元测试要做多细?”

标签: 杂项资源 | 发表时间:2012-09-03 01:03 | 作者:陈皓
出处:http://coolshell.cn

这篇文章主要来源是StackOverflow上的一个回答——“ How deep are your unit tests?”。一个有13.8K的分的人( John Nolan)问了个关于TDD的问题,他说——

“TDD需要花时间写测试,而我们一般多少会写一些代码,而第一个测试是测试我的构造函数有没有把这个类的变量都设置对了,这会不会太过分了?那么,我们写单元测试的这个单元的粒度到底是什么样的?并且,是不是我们的测试测试得多了点?”

八卦一个答案

StackOverflow上,这个问题的答案是这样的——

“I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.”

老板为我的代码付报酬,而不是测试,所以,我对此的价值观是——测试越少越好,少到你对你的代码质量达到了某种自信(我怀疑这种的自信标准备要高于业内的标准,但这种自信也可能是种自大)。如果我的编码生涯中不会犯这种典型的错误(如:在构造函数中设了个错误的值),那我就不会测试它。 我倾向于去做那些有意义的错误测试,所以,我对一些比较复杂的条件逻辑会异常地小心。当在一个团队中,我会非常小心的测试那些会让团队容易出错的代码。

Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. Ten or twenty years from now we’ll likely have a more universal theory of which tests to write, which tests not to write, and how to tell the difference. In the meantime, experimentation seems in order.”

不同的人有不同的测试方式,在如今这种不成熟的时期,这些能够适应于内部编码的测试方式对我来说都比较合理。也许从今后十年或二十年,我们会对“什么要的测试需要写,什么样的不需要”达成更广泛的共识,并且我们可以知道这两者的区别。与此同时,各种实践都在各自发生中。

这个问题并不新鲜,但是这个回答对TDD似乎有一种否定, 最亮的是这个问题是由 Kent Beck,Kent是XP和TDD的创造者,是敏捷开发实践方法的奠基人。以致于还有人调侃到——

The world does not think that Kent Beck would say this! There are legions of developers dutifully pursuing 100% coverage because they think it is what Kent Beck would do! I have told many that you said, in your XP book, that you don’t always adhere to Test First religiously. But I’m surprised too.

只是要地球人都不会觉得Kent Beck会这么说啊!我们有大堆忠实程序员在追求着100%的代码测试覆盖率,因为这些程序员觉得Kent Beck也会这么!我告诉过很多人,你在你的XP的书里说过,你并不总是支持“宗教信仰式的Test First”,但是今天这么说,我还是很惊讶!

后面还有一些不人同意Kent, 我一下子从这个事中想到了《 fight club》里的那个精神分裂者创建了一个连自己都反对的地下组织。呵呵。

其它答案

八卦完了,我们还是来认认真真地看看这个问题中其它的其它答案。

第二个答案:值得借鉴

  • 开发过程中,单元测试应该来测试那些可能会出错的地方,或是那些边界情况。
  • 维护过程中,单元测试应该跟着我们的bug report来走,每一个bug都应该有个UT。于是程序员就会对自己的代码变更有两个自信,bug 被 fixed,相同的bug不会再次出现。

第三个答案:给敏捷咨师看的答案

这个答案在说,我们只注意到了TDD中的T,而忽略了第一个D,就是Driven…… bla bla bla… 又这扯这些空洞的东西了,国内的各种不学无术的敏捷咨询师最好这一口了。

第四个答案:致那些什么都要测试的人

如果我们需要测试一个像  int square(int x) 这样的开根函数,我们需要40亿个测试(每个数都要测试)。

事实上这种情况可能还更糟糕,如果有这样一个方法  void setX(int newX) 不会更改其它的成员变量,如:obj.z, Obj.y,那么,你是不是还要去测试一下别的变量没有被改变?

 

因为,在国内也有很多很多人在问这类的问题——单元测试究竟要做多细?

 


(转载本站文章请注明作者和出处 酷壳 – CoolShell.cn ,请勿用于任何商业用途)

————————============ 感谢 42qu.com 为本站提供 VPS ============————————
您可能也喜欢:

如何在低速率网络中测试 Web 应用

十个免费的Web压力测试工具

我们需要专职的QA吗?

我们需要专职的QA吗? | 酷壳 - CoolShell.cn

Web程序的最佳测试数据
无觅

随便看看

相关 [单元测试 做多] 推荐:

“单元测试要做多细?”

- - 酷壳 - CoolShell.cn
这篇文章主要来源是StackOverflow上的一个回答——“ How deep are your unit tests?”. 一个有13.8K的分的人( John Nolan)问了个关于TDD的问题,他说——. “TDD需要花时间写测试,而我们一般多少会写一些代码,而第一个测试是测试我的构造函数有没有把这个类的变量都设置对了,这会不会太过分了.

Android单元测试

- - CSDN博客推荐文章
    单元测试不管对于初学编程还是已经工作了很久的开发者来说,都不乐意花时间去写认为没用的代码进行测试,只要交给测试人员就行了,虽然这样也能把软件改出来,但也许你要花上几倍的时间去修改问题,如果在开发的过程中花点时间去写单元测试代码,把尽可能出问题的地方都测试一遍,把问题扼杀在最开始的地方,这样你就不必为后来找问题出处而烦恼.

Hadoop之MapReduce单元测试

- - ITeye博客
通常情况下,我们需要用小数据集来单元测试我们写好的map函数和reduce函数. 而一般我们可以使用Mockito框架来模拟OutputCollector对象(Hadoop版本号小于0.20.0)和Context对象(大于等于0.20.0). 下面是一个简单的WordCount例子:(使用的是新API).

文章: Android中的单元测试

- - InfoQ cn
随着Agile的普及,以及开发人员对测试重要性的认识逐步加深,单元测试已经成了越来越多软件项目开发中不可缺少的一部分. 无论项目是不是采用TDD的形式来进行开发,单元测试都能够为项目的修改和重构提供一定的保障. 有奖参与:天翼伦敦会,上传应用,为中国队加油. QClub七月技术沙龙(太原/北京/上海/厦门/西安 7月21/28/29日 免费报名中.

迈出单元测试的第一步

- - 酷勤网-挖经验 [expanded by feedex.net]
单元测试不仅是软件行业的最佳实践,在敏捷方法的推动下,它也成为了可持续软件生产的支柱. 年度敏捷调查,70%的参与者会对他们的代码进行单元测试. 单元测试和其他敏捷实践密切相关,所以开始编写测试是组织向敏捷转型的踏脚石. 我将在本文介绍符合要求的小技巧,以及在开发周期里进行单元测试的步骤. 没有自动化,单元测试的习惯也不会持续太久.

iOS开发进阶之单元测试

- - 博客园_首页
本文侧重讲述如何在iOS程序的开发过程中使用单元测试. 使用Xcode自带的OCUnit作为测试框架. 单元测试作为敏捷开发实践的组成之一,其目的是提高软件开发的效率,维持代码的健康性. 其目标是证明软件能够正常运行,而不是发现bug(发现bug这一目的与开发成本是正相关的,虽然发现bug是保证软件质量的一种手段,但是很显然这与降低软件开发成本这一目的背道而驰).

Java 单元测试利器之 Junit

- - 博客园_首页
          因为工作和学习的需要,在代码中查错的时候,第一步就是想知道这个错误具体发生在一个位置,进行一个准确的定位. 而这个定位的工作交给谁来做了呢. 不难猜出也就是这篇博客的主题---Junit. junit是一个开源的框架,也是java这一块的测试工具之一. 想了解详细请上官网,下面用代码来跟大家解释.

单元测试里的 5 个错误

- - ITeye博客
当我第一次听说可以使用框架比如JUnit来进行单元测试的时候,我惊叹这真是一个简单而强大的概念. 它取代了随机测试,使你可以保存你的测试代码,并按照需要随时运行它们. 按照我的理解,关于单元测试并没有多少产生误解的可能. 但是过去的几年中,我确实见过几种或多或少不太正确的单元测试使用方式. 如果跟协作逻辑代码分离开来,那么算法逻辑是最容易测试的.

使用DBUnit做单元测试

- - BlogJava-qileilove
 DBUnit是一个方便的数据准备工具, 方便于我们做. 单元测试的时候准备数据, 它的数据准备是基于XML格式的, 如下:.   DBUnit的一个XML数据文件中,可以同时放多个表的数据,并且可以方便的把上面XML中准备的数据插入倒. 只需要使用下面简单的代码就可以做到:.    注:准备这处XML数据文件时,一定要把同一个表中字段数最多的记录放在前面,因为DBUnit在根据数据XML文件准备表的元数据字段的时候,是以当前表的第一记录为主的.

Android单元测试研究与实践

- - 美团点评技术团队
处于高速迭代开发中的Android项目往往需要除黑盒测试外更加可靠的质量保障,这正是单元测试的用武之地. 单元测试周期性对项目进行函数级别的测试,在良好的覆盖率下,能够持续维护代码逻辑,从而支持项目从容应对快速的版本更新. 单元测试是参与项目开发的工程师在项目代码之外建立的白盒测试工程,用于执行项目中的目标函数并验证其状态或者结果,其中,单元指的是测试的最小模块,通常指函数.