As  Kevin Taylor writes: ....Its primary purpose is code design. .... How does it lead to better code design? Test first development works like this. ..... Developer is designing the application's API

有几天没有认真更新了。 我只是不愿意在自己低落，没有目标，或者浪费了时间的日子里，把不好的情绪再蔓延。前二天一直无法找到状态，整天的时间就是看，看了很多的东西，又好像没留下什么。不能，不能这样。 从昨天开始学习单元测试，早上又看了几篇。TDD真是个好主意，尤其老是不能把一个类功能确定下来，总是造成类间耦合比较高的人，先写测试就像给自己定了明确的目标，先从一个调用者的角度去思考，这样你会写出更容易调

测试驱动开发（Test-Driven Development）简称TDD，是以测试作为软件开发的核心，将测试贯穿于软件开发工程的方法论，TDD同时也是XP（极限编程）的核心之一。对Java程序员来说，可能大家都认为就是JUnit，编写TestCase就可以，但是在其背后，Refactor（重构）和Intention Programming（意图编程）却起着非常重要的作用。 重构在两个方面和TDD密

大名鼎鼎的Rod Johnson,日益流行的敏捷方法学,极具潜力的xp分支,又是xp核心的tdd,还有什么好说的,特转载如下: http://www.theserverside.com/news/thread.tss?thread_id=32394#160253 Why do I like TDD? 1) by the nature of software engineering any code

        看书看不下去，索性就把这段时间以来的学习笔记放一点上来。这里的全部都是理论上的东西，具体的实践近期是不大可能会有的，诶，理论是有点乏味，可还是要学。就像数学一样的。         TDD和模式的笔记，TDD的那本书看完了，不过没有深刻地看，等到暑假再说咯。模式现在还在看，这书太厚啦，一章章地看下来累得死一头牛。没办法，坚持，就是胜利。         数值对象的一个要求就是一旦它

Michael Feathers在Artima自己的Blog中 2005-9-9 发表了一篇A Set of Unit Testing Rules的文章，提出了如下的代码不是单元测试： 1.        访问数据库It talks to the database 2.        访问网络It communicates across the network 3.        访问文件系统It

这些年来，我喜欢用下面这三条简单的规则来描述测试驱动开发： 除非这能让失败的单元测试通过，否则不允许去编写任何的产品代码。 只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败） 只允许编写刚好能够导致一个失败的单元测试通过的产品代码。 对于任何功能，一定要从编写它的单元测试开始；但是到了原则2，你就不能再为那个单元测试写更多内容。只要一出现该单元测试代码编译失败，或是断言失败，你就必

这些年来，我喜欢下面三条简单的规则来描述测试驱动开发： 除非这能让失败的单元测试通过，否则不允许去编写任何的产品代码。 只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败） 只允许编写刚好能够导致一个单元测试失败的产品代码。 对于任何功能，一定要从编写它的单元测试开始；但是到了原则2，你就不能再为那个单元测试写更多内容。只要一出现该单元测试代码编译失败，或是断言失败，你就必须停下来开

看到一点关于TDD(Test Driven Development)的精辟论述,原文如下: Actually, writing unit test makes you think (or, design). For example, with TDD method, you can hardly write tight-coupled code, because it's difficult to

这两天翻了下 Kent  Beck 的 Test-Driven Development By Example 感觉还不错,第一部分的例子讲的挺好,本来想归纳一下,貌似太长了,等有时间了再归纳下,最后看到了附录里面的一个Fibonacci数列的例子感觉也有那么点TDD的味道在里面,总结分享一下: 让我们从最简单的fibonacci(0)=0开始吧,先写测试如下: java 代码 import jun

很多小公司不注重文档，软件开发只有代码，牛人走了项目就基本无法增强。 而所谓的通过CMM4的大公司，却只会僵硬的流程还是流程，文档还是文档。大型项目写代码的时间居然只有2周，而测试却用了4个月。 2个极点都是软件开发的噩梦，但在中国又是那么的正常。 TDD真的太好了，这是我见过的，解决当前软件危机最好的保证。TDD是编程思维的一次革命，是真正的以接口设计导向。  

Robert C. Martin大叔总结的TDD的三条军规，简直太到位了： 1.除非这能让失败的单元测试通过，否则不允许去编写任何的产品代码。 2.只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败） 3.只允许编写刚好能够导致一个失败的单元测试通过的产品代码。 对于任何功能，一定要从编写它的单元测试开始；但是到了原则2，你就不能再为那个单元测试写更多内容。只要一出现该单元测试代码编

  命名 测试用例的名字应该描述需求, 不要描述实现. 取决于你要沟通交流传递的信息, Test Case 有至少两个作用 检查你的产品代码是否按预期工作, 这由函数体来完成 表达你的预期,让阅读代码的人知道你的产品能够干什么,如何使用, 甚至如何设计的;这除了函数体的assert语句外,Test case的名字更是重要的手段 但我们通常只会为一段测试代码起一个名字, 而要表达的信息如此之多, 怎

一、起因 　　公司交给我一个任务，为测试员写一个手机模拟界面，以方便她们的手机短信测试。过去她们都是用MC4J直接调用公司服务器的MBean服务来模拟进行测试，以验证我们整个系统平台。这种测试主要是检查收发短信是否正常，而我的要做的工作就是，让她们在测试的时候更方便更直观。 二、需求 　　我和测试员陈MM（也就是软件的使用者）约定了一个时间，大家一起来讨论这个软件的需求。 　　1、首先，我大概了解

【原文写于14 January 2007 ，注】   cppUnit & mockpp cppUnit: http://cppunit.sourceforge.net/ mockpp: http://mockpp.sourceforge.net/ JSUnit httpUnit Selenium: http://www.openqa.org/selenium/  

tdd开发模式，其实就和软件开发流程一样的。先有需求，再有代码的流程。 而tdd就是这样的一个流程。先写好测试，确定需求，再根据需求做设计。 

测试驱动开发 （Test-Driven Development， TDD ）是通过测试定义所要开发的功能的接口，然后实现功能的开发过程。       Test-Driven Development(TDD)，是Extreme Programming (XP)--极限编程的一个重要组成部分。       在上面的图中，列出的的是XP的12个团队实践。Test-Driven Development是其

cnfree 写道 TDD又不是万试万灵的，像GUI这一块根本无法使用TDD，TDD只能用在Model以及单元逻辑这一部分，但是简单的逻辑没有问题，不代表复杂的逻辑组合没有问题，而这一点TDD能否做到？实际上最后还是要靠常规的测试体系来保障软件的开发。软件开发始终还是需要靠需求来驱动。TDD决不是神。 taowen     2007-09-22 19:37 GUI的TDD可以做啊。如果你的GUI框

测试驱动开发的操作非常简单。 1、编写测试代码 2、运行测试用例，发现用例不通过 3、增加少量实现代码 4、运行测试用例，用例通过 5、重构 其中有三个比较关键的因素：测试、节奏、驱动。 测试驱动开发首先要讲的就是测试了。以前在一个项目中，我需要写一个带有非常复杂业务的计算类。当时对于能否写出来完全没有信心，主要是情况太复杂，分支特别多。其中涉及到表达式的解析，自定义变量的引用关系，数据的汇总计算

  　　　　　　　　　　　　文/陈刚 at 2006年4月12日　from www.ChenGang.com.cn 前段时间把一个界面框架完成了，今天基于这个框架开发一个小模块，在这里把这个模块设计的全过程记录下来，希望大家讨论并指正。 一、起因 公司交给我一个任务，为测试员写一个手机模拟界面，以方便她们的手机短信测试。过去她们都是用MC4J直接调用公司服务器的MBean服务来模拟进行测试，以验证