“单元测试要做多细?”
这篇文章主要来源是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 tha ...
Test-Driven Development?别逗了
这篇文章来源于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 ...
在新浪微博上关于敏捷的一些讨论
自从我发布了“Scrum为什么不行”,并被CSDN推成首页头条后,我在我的新浪微博上就经常被敏粉们@去讨论他们的一些话题。他们似乎想要从我这里听到一些不同的声音,我很喜欢他们的这种态度,在这里先赞他们一个。既然,让我来评论他们的东西,我就不客气了,板砖自然是少不了的。 我觉得我在微博上的观点比较散,所以在这里做一个汇总。我在所有批评敏捷的文章里都重复说过我的立场,这里还要再说一遍,因为那群人很敏感——“我承认敏捷中有一些东西我是认可的,但对敏捷社区的推广和思维方式我持否定态度”。
目录
敏捷词汇表
敏捷宣言
博文评论
后续
糊弄客户?
敏捷词汇表
我被@吴穹adam邀请进入了一个敏捷词汇表的微群,这个群就是想明确的定义一下敏捷的各种词汇,比如,他们想把TDD定义成就是UT。呵呵。我对这个群仅保持了30分钟的热度,我在里面发了一个“你们不想讨论技术吗?”的帖子,就再也不想关注了。因为我的观点如下:
我不知道干这件事有什么意义。标准化还是洗脑?One World, One Agile? – horse sh ...
Bob大叔和Jim Coplien对TDD的论战
今年春节时,我写了一篇《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 ...
敏捷水管工
本文来自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 spon ...
再谈敏捷和ThoughtWorks中国咨询师
目录
前言说明
基本观点
对于敏捷方法论的观点
对于ThoughtWorks咨询师的批评观点
关于ThoughtWorks和InfoQ给我的信
前言说明
之所以用了“再”,是因为之前的两篇文章——
我在《那些炒作过度的技术和概念》中批评了ThoughtWorks中国咨询师的咨询方法是以一种接近于教条、炒作、洗脑和电视购物的方法(虽然我心底觉得有时候有时候更像传销),当然,批评是没有意义的,所以我也给了中国ThoughtWorks那些年轻的咨询师们一些我认为有建设性的建议。
我在《TDD并不是看上去的那么美》一文中列举了一些在实际中使用TDD可能会出现的问题和难题,以此来告诉大家在使用TDD时需要注意的东西。就像是在《结对编程的利与弊》说的一样,只有真正知道一件事情的利弊,你才能用好它。
当然,这两篇文章都不可避免得招来了ThoughtWorks咨询师和Agile信仰者们的很多回复,我也有开始沉不住气回复了很多,当然,有一半以上的不是学术上的讨论,而是对我个人的攻击。甚至,在这两篇文章发布后,酷壳(Cool ...
[转]TDD到底美还是不美?
下面的文章转自Todd Wei 的《TDD到底美还是不美?》,对于这篇文章,我个人能过透过作者的观点感受到他的项目中使用TDD的难点,同样可以感受到作者内心的纠结。不管怎么样,我能够感到作者Todd Wei在独立思考,独立思考总是好的,因为那是走向成熟的必要条件。(另,大家可以移步过去看看相关的评论,挺有意思的)
————————————————————————————————————
最近CoolShell上的一篇《TDD并不是看上去的那么美》引起了敏捷社区的高度关注和激励辩论。今天,InfoQ甚至专门举行了一个“虚拟座谈会”《TDD有多美?》,几位国内敏捷社区的名人专门就此问题展开了深入地讨论。不论结果如何,这个纯技术的探讨精神还是非常值得赞赏的。事件实际上可以简单地归纳为“一个有一定影响力的开发人员质疑TDD,一群敏捷社区名人对TDD进行解释和辩护”。现在,就让我坚定地站在CoolShell一边,为对TDD的质疑和批判添砖加瓦吧!
TDD的核心理念是什么呢?第一是Specification by Example,即把测试用例作为表达需求的一种方式。传统的需求表 ...
TDD并不是看上去的那么美
春节前的一篇那些炒作过度的技术和概念中对敏捷和中国ThoughtWorks的微辞引发了很多争议,也惊动了中国ThoughtWorks公司给我发来了邮件想来找我当面聊聊。对于Agile的Fans们,意料之中地也对我进行了很多质疑和批评。我也回复了许多评论。不过,我的那些回复都是关于中国ThoughtWorks咨询师以及其咨询的方法的。我对Agile方法论中的具体内容评价的不是很多,所以,我想不妨讨论一下Agile方法论中的具体的实践(以前本站也讨论过结对编程的利与弊)。
那么,这次就说说TDD吧,这是ThoughtWorks中国和Agile的Fans们最喜欢的东西了。我在原来的那篇文章中,我把TDD从过度炒作的技术剔除了出去,因为我还是觉得TDD有些道理的,不过,回顾我的经验,我也并不是很喜欢TDD。我这篇文章是想告诉大家,TDD并没有看上去的那么美,而且非常难以掌控,并且,这个方法是有悖论之处的。
TDD简介
TDD全称Test Driven Development,是一种软件开发的流程,其由敏捷的“极限编程”引入。其开发过程是从功能需求的test case开始,先添加一个test ...