web analytics

存档

文章标签 ‘TDD’

“单元测试要做多细?”

2012年9月3日 68 条评论 18,835 人阅读    

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

“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.”

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

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

阅读全文…

分类: 杂项资源 标签: , ,
好烂啊有点差凑合看看还不错很精彩 (13 人打了分,平均分: 4.54 )
Loading ... Loading ...

Test-Driven Development?别逗了

2011年10月17日 45 条评论 12,703 人阅读    

这篇文章来源于Peter Sergeant在Write More Test 博客上的《Test-Driven Development? Give me a break…》,在原文和Reddit 上有很大反响。这篇文章里的很多观点在《TDD并不是看上去的那么美》和《再谈敏捷和TW咨询师》里都出现过(我个人觉得我的观点比其更全面一些)。就像我转的《Scrum为什么不行》 和《Bob大叔和Jim Coplien对TDD的论战》一样,从这些贴子我们可以看到——这是一个全世界的问题,并不是只有在中国才有的问题

很多敏粉都在说我在是喷敏捷,黑敏捷,向敏捷泼脏水,我只想对这些人说——你们这样的见解很肤浅也很敏感,你们根本就没有认识到——争论,反思和不同观点的意义,你也就无法了解你们所信仰的敏捷!你们只是在肤浅和盲目地信仰和教条敏捷中的许多名词、方法和标准答案罢了

——————————————正文开始——————————————

对于程序员来说有些事有非常危险的信号(red flag)。当我听到有人开始信仰Test-Driven Development 是 One True Programming Methodology(唯一正确的编程方法论),这就是危险信号(red flag),我开始假设你是一个劣等、没有经验的程序员,或是某些敏捷咨询师。

测试只是一个工具来帮助你,而不是用来证明谁比谁更虔诚,或是我的屌比你的要大,等这种愚蠢的行为。测试是用来让程序员得到有帮助的、更快的反馈,从而找到正确的路径,如果你搞坏一些事,其还可以用来给后人一些警告。这根本就不是一个神秘的有魔力的方法其可以让你的代码变得更好……

整个Test-Driven Development的概念是麻痹和信奉,从而让其成为你的人生观。相反的:Developer-Driven Testing,它给你和你的同事一些有用的工具来解决问题,来支持你自己,而不是那种以工具或方法为中心的让你假设其应该是那样的测试。

阅读全文…

分类: 杂项资源, 流程方法 标签: ,
好烂啊有点差凑合看看还不错很精彩 (10 人打了分,平均分: 4.60 )
Loading ... Loading ...

在新浪微博上关于敏捷的一些讨论

2011年8月12日 52 条评论 6,751 人阅读    

自从我发布了“Scrum为什么不行”,并被CSDN推成首页头条后,我在我的新浪微博上就经常被敏粉们@去讨论他们的一些话题。他们似乎想要从我这里听到一些不同的声音,我很喜欢他们的这种态度,在这里先赞他们一个。既然,让我来评论他们的东西,我就不客气了,板砖自然是少不了的。 我觉得我在微博上的观点比较散,所以在这里做一个汇总。我在所有批评敏捷的文章里都重复说过我的立场,这里还要再说一遍,因为那群人很敏感——“我承认敏捷中有一些东西我是认可的,但对敏捷社区的推广和思维方式我持否定态度”。

敏捷词汇表

我被@吴穹adam邀请进入了一个敏捷词汇表的微群,这个群就是想明确的定义一下敏捷的各种词汇,比如,他们想把TDD定义成就是UT。呵呵。我对这个群仅保持了30分钟的热度,我在里面发了一个“你们不想讨论技术吗?”的帖子,就再也不想关注了。因为我的观点如下:

  • 我不知道干这件事有什么意义。标准化还是洗脑?One World, One Agile?  - horse shit!
  • 你能定义地好吗?定义好了大家都能干好了? - 幼稚!
  • 理解不同又有什么关系?价值观不同又能怎么样?为什么不能正视并接受世界的不同呢? –  固执!

敏捷宣言

我看到很多人又把《敏捷宣言》拿出来说事,就好象他们把敏捷宣言是软件开发的普世的价值观一样。我对此的评论是—— 阅读全文…

分类: 技术管理, 流程方法 标签: , ,
好烂啊有点差凑合看看还不错很精彩 (10 人打了分,平均分: 4.40 )
Loading ... Loading ...

Bob大叔和Jim Coplien对TDD的论战

2011年6月27日 41 条评论 8,571 人阅读    

今年春节时,我写了一篇《TDD并不是看上去的那么美》,在这篇文章中我列举了一些关于使用TDD的一些难点和对TDD的质疑,后来出现了一些争论(可参见那篇文章的评论),以及Todd同学的《TDD到底美不美》,还有infoQ中文上的那个几乎没有营养离线讨论。今天,有网友给我推来一个英文版infoQ的视频——“Coplien and Martin Debate TDD, CDD and Professionalism”,这是2008年2月18日的视频,视频的主角两个人争论TDD好还是不好,一个是敏捷社区的教主级的人物——Robert Martin(大家称之为“Bob大叔”),另一个是C++,OO,多范式编程的大师Jim Coplien(大家都叫他Cope)。这两个人对TDD的见解有分歧。Coplien的很多观点和我之前的不谋而合,而他自己称他是坚决强烈地站在TDD的对立面上。下面是Jim的原话:

I have adopted a very strong position against what particularly the XP community is calling test driven development.

InfoQ的视频很多时候相当的不给力,就像有前列腺的患者撒尿一样,半天都挤不出一滴。不过,好在那里有这两个人对话的摘录。在这里,我给大家摘要一下:

——————————————————正文分割线————————————————————

Coplien首先让Uncle Bob定义了一下TDD,Uncle Bob说明了他的三个法则:(敏捷的同学一定不陌生)

  1. 一个测试驱动的程序员,其不会在写出一个测试失败的Unit Test前,去写一句可用在生产线上的代码。(没有测试之前不要写任何功能代码)
  2. 在编写用于生产线上代码之前,不写过多的测试失败的Unit Test。(只编写刚好能体现一个失败情况的测试代码)
  3. 在现有代码通过Unit Test前,不写更多的用于生产线上的代码。(只编写恰好能通过测试的功能代码)

Coplien说他有意见的不是这三个法则,而是因为这个三个法则是孤立说出来的。Coplien说他和一些咨询师或是Scrum Master参与过很多的项目,他们发现这些项目都有两个问题:

  1. 他们使用TDD的时候,软件没有一个架构或是framework。当然,Kent Beck说——TDD可以驱使你去做架构。但是,TDD和Unit Test 是一回事吗?Unit Test是一个伟大的事,尤其是当你去写API和类库的时候。今天XP所说的TDD和UT很不一样。如果你使用TDD来驱动你的软件系统架构,那么,基本上来说,三个迭代以后,你开发的软件就会crash掉,而且无法再往前开发。 因为什么?因为连软件团队自己都受不了这三个迭代出来的架构,而且你还会发现,你根本没去去重构。
  2. 第二个问题是,TDD这种方法破坏了GUI(图形界面),就算是Kent也说:“你永远不可以在一个漂亮的界面后面隐藏一个糟糕的架构”,Coplien强烈地相信软件的架构是通过界面来发出其光芒。他觉得如果没有一个好的软件架构,这个会影响用户的操作。

Coplien接着说,如果我们使用Uncle Bob的三条法则,我们也许没有什么问题,但Coplien想告诉大家另一个非常重要的事,那就是软件架构。并说:“我根本不接受TDD是软件专业化实践的论点”

阅读全文…

好烂啊有点差凑合看看还不错很精彩 (4 人打了分,平均分: 5.00 )
Loading ... Loading ...

敏捷水管工

2011年2月25日 27 条评论 4,609 人阅读    

本文来自Terazen Technology Inc的创始人+CTO的 David Ing的《Agile Plumbers》(这也墙?),我的其文中的这个帮事翻译过来(和前些天发的SOAP的S是Simple异曲同工)。

也许你会觉得这个比喻不恰当。但我想告诉你的是,这个故事告诉我们,教条主义和以方法论为中心的危险。十条不错的编程观点中第一条—— The only “best practice” you should be using all the time is “Use Your Brain”.

————————————————————

(门铃响……)

事主:啊, Agile 水管工吗? 请进,感谢谢你们这么快就来了——这的确很紧急,我这真是很乱。

水管工1: 先生,没问题,我们就是敏捷的。在我给你做Presentation前,我先给你介绍一下我的两个同事。

事主:Presentation?啊,我们有时间吗?这的水已经流得到处都是了……

水管工1:……先生,我们必需坚持这个。我们只是想保证你能成为动态搜寻解决方法的一份子。你是我们的 champion sponsor,也就是我们团队内的 consultant!你可以提供一个白板给我们使用吗?

事主:我没听懂,你们不觉得这变复杂了吗?我觉得我应该告诉你们这水是从房子哪儿流出来的,就是那……

水管工2:你这有让我脱衣服的地儿吗?

事主:什么?

阅读全文…

好烂啊有点差凑合看看还不错很精彩 (13 人打了分,平均分: 4.69 )
Loading ... Loading ...

再谈敏捷和ThoughtWorks中国咨询师

2011年2月24日 117 条评论 24,038 人阅读    

前言说明

之所以用了“再”,是因为之前的两篇文章——

  • 我在《那些炒作过度的技术和概念》中批评了ThoughtWorks中国咨询师的咨询方法是以一种接近于教条、炒作、洗脑和电视购物的方法(虽然我心底觉得有时候有时候更像传销),当然,批评是没有意义的,所以我也给了中国ThoughtWorks那些年轻的咨询师们一些我认为有建设性的建议。
  • 我在《TDD并不是看上去的那么美》一文中列举了一些在实际中使用TDD可能会出现的问题和难题,以此来告诉大家在使用TDD时需要注意的东西。就像是在《结对编程的利与弊》说的一样,只有真正知道一件事情的利弊,你才能用好它。

当然,这两篇文章都不可避免得招来了ThoughtWorks咨询师和Agile信仰者们的很多回复,我也有开始沉不住气回复了很多,当然,有一半以上的不是学术上的讨论,而是对我个人的攻击。甚至,在这两篇文章发布后,酷壳(CoolShell.cn)受到持续性的黑客攻击

本来已经过去的事,今天却又发现这两篇文章的访问量和评论又上来了,才发现原来是InfoQ的这篇文章——《虚拟座谈会:TDD有多美?》,加上很多我在评论中的观点,以及ThoughtWorks和InfoQ之前给我的来信中谈到的一些观点。我很不自然地想把我的一些观点总结并罗列在这里。主要分成四块—— 1)我对整个事情的基本观点,2)对于方法论的观点,3)对于TW中国咨询师的观点,4)还有和TW和InfoQ住来信件中的观点

————————————————

基本观点

首先,我想说明一下我的基本观点。

阅读全文…

好烂啊有点差凑合看看还不错很精彩 (34 人打了分,平均分: 4.82 )
Loading ... Loading ...

[转]TDD到底美还是不美?

2011年2月24日 29 条评论 4,371 人阅读    

下面的文章转自Todd Wei 的《TDD到底美还是不美?》,对于这篇文章,我个人能过透过作者的观点感受到他的项目中使用TDD的难点,同样可以感受到作者内心的纠结。不管怎么样,我能够感到作者Todd Wei在独立思考,独立思考总是好的,因为那是走向成熟的必要条件。(另,大家可以移步过去看看相关的评论,挺有意思的)

————————————————————————————————————

最近CoolShell上的一篇《TDD并不是看上去的那么美》引起了敏捷社区的高度关注和激励辩论。今天,InfoQ甚至专门举行了一个“虚拟座谈会”《TDD有多美?》,几位国内敏捷社区的名人专门就此问题展开了深入地讨论。不论结果如何,这个纯技术的探讨精神还是非常值得赞赏的。事件实际上可以简单地归纳为“一个有一定影响力的开发人员质疑TDD,一群敏捷社区名人对TDD进行解释和辩护”。现在,就让我坚定地站在CoolShell一边,为对TDD的质疑和批判添砖加瓦吧!

TDD的核心理念是什么呢?第一是Specification by Example,即把测试用例作为表达需求的一种方式。传统的需求表达方式包括文档,Use Case等,而TDD强调通过测试用例来表达需求。另外,TDD的测试用例是黑盒的基于外部接口的,所以,它实际上又是对外部接口的设计。如何看待测试用例是TDD与传统测试的一个重要区别。“不把测试用例单纯地视为测试,而从需求和设计的角度来看测试用例”的理念本身是好的。另外,TDD的第二个理念是Test First,强调测试对于实现的驱动作用,先写测试用例,再实现和重构。在Specification by Example的理念下,Test First的实质是“先理解清楚需求,并做好外部接口设计,把它转化为测试用例,然后再来实现和重构”。

我认为,Specification by Example是不错的,因为测试用例作具有精确性,容易自动化的优点,这是传统的文档和Use Case在表达需求时所欠缺的地方。但Test First理念本身则有很大的问题,尤其“在没有测试用例失败之前,不要写任何一行代码”的极端方式则更是极端的错误。
阅读全文…

分类: 流程方法 标签: ,
好烂啊有点差凑合看看还不错很精彩 (9 人打了分,平均分: 4.44 )
Loading ... Loading ...

TDD并不是看上去的那么美

2011年2月12日 67 条评论 18,749 人阅读    

春节前的一篇那些炒作过度的技术和概念中对敏捷和中国ThoughtWorks的微辞引发了很多争议,也惊动了中国ThoughtWorks公司给我发来了邮件想来找我当面聊聊。对于Agile的Fans们,意料之中地也对我进行了很多质疑和批评。我也回复了许多评论。不过,我的那些回复都是关于中国ThoughtWorks咨询师以及其咨询的方法的。我对Agile方法论中的具体内容评价的不是很多,所以,我想不妨讨论一下Agile方法论中的具体的实践(以前本站也讨论过结对编程的利与弊)。

那么,这次就说说TDD吧,这是ThoughtWorks中国和Agile的Fans们最喜欢的东西了。我在原来的那篇文章中,我把TDD从过度炒作的技术剔除了出去,因为我还是觉得TDD有些道理的,不过,回顾我的经验,我也并不是很喜欢TDD。我这篇文章是想告诉大家,TDD并没有看上去的那么美,而且非常难以掌控,并且,这个方法是有悖论之处的

TDD简介

TDD全称Test Driven Development,是一种软件开发的流程,其由敏捷的“极限编程”引入。其开发过程是从功能需求的test case开始,先添加一个test case,然后运行所有的test case看看有没有问题,再实现test case所要测试的功能,然后再运行test case,查看是否有case失败,然后重构代码,再重复以上步骤。其理念主要是确保两件事:

  • 确保所有的需求都能被照顾到。
  • 在代码不断增加和重构的过程中,可以检查所有的功能是否正确。

我不否认TDD的一些有用的地方,如果我们以Test Case 开始,那么,我们就可以立刻知道我们的代码运行的情况是什么样的,这样可以让我们更早地得到我们实现思路的反馈,于是我们更会有信心去重构,去重新设计,从而可以让我们的代码更为正确。

不过,我想提醒的是,TDD和Unit Test是两码子事儿。有很多人可能混淆了自动化的Unit Test(如:XUnit系例)和TDD的软件开发过程。另外,可能还会有人向鼓吹“TDD让你进行自顶向下的设计方式”,对此,请参阅本站的《Richard Feynman, 挑战者号, 软件工程》——NASA的挑战者号告诉你自顶向下设计的危险性。

TDD的困难之处

下面是几个我认为TDD不容易掌控的地方,甚至就有些不可能(如果有某某TDD的Fans或是ThoughtWorks的咨询师和你鼓吹TDD,你可以问问他们下面这些问题)

  • 测试范围的确定。TDD开发流程,一般是先写Test Case。Test Case有很多种,有Functional的,有Unit的,有Integration的……,最难的是Test Case要写成什么样的程度呢。
    阅读全文…
分类: 流程方法 标签: ,
好烂啊有点差凑合看看还不错很精彩 (25 人打了分,平均分: 4.48 )
Loading ... Loading ...