很长时间没有自己写博客了，前两个月看了一些关于测试驱动开发（Test-Driven Development, 简称TDD）和敏捷软件开发（Agile Software Development）是否有用、是否一定得用的争论，很精彩，也很引人思考。尤其感谢酷壳网的站长陈皓先生将这些观点搜罗起来并发表了自己的看法。   　　在我的同事（尤其是小利）面前，我一直装着是个敏捷的忠实粉丝，但是严格的来讲

以后开发一定要测试先行！坚持TDD和BDD开发方法，不能贪容易，贪快。 后期代码的维护和测试，升级，都需要依赖Test Case！ 座右铭： 不测试，不编程！

《测试驱动开发》，弱弱的看了几十面，实在看不下去了。反正觉得总体一句话：首先确定测试（需要的功能），再快速的做出来，再在此基础上进行修改。 TDD（Test-driven development）测试驱动开发，是极限编程（XP）最常用的一种方式。即使你不是采用的极限编程这种软件开发方法，也应该采用。因为这种方式可以让你的代码整洁好用。 我们将建立一个计划清单，当开始某项工作时，就用粗体表示，而如果

全量测试又慢又难以定位错误, 其所需的测试环境的维护成本也很高. 解决方案就是化整为零分别测试. 然而引入新的问题: 测某个"部分"时所需的依赖如何满足. 解决方案是一组被称为"测试替身(Test Double)"的技术. 我们来看一下这里面具体的问题 为了能编译通过, 我需要依赖被满足 为了能正常运行, 我希望依赖的实现不要出错 为了覆盖到真实场景下的用例, 我需要依赖能够模拟真实场景下的行为,

         相信程序猿们敲代码时都经历过这种阶段。一开始，怀着极大地志向，打算把代码写的尽量优雅，各个方法清晰易读。但随着时间的推移，项目的逐步增长，发现代码越写越乱，自己花费了大量的时间在代码的调试上，经常是改了一处，却牵扯到其他众多地方，级联的错误，而导致你把大量的时间花费在回忆自己先前的逻辑与代码调试中，而陷入了“焦油坑”中。经过了这个过程，心中唯一想做的就是尽快把这份代码写完，早些摆

测试驱动开发TDD的好处： 1. 快速反馈 2. 有利于解偶，不好测试的用例需要重构 3. 测试用例是重构的基础， 4. 先定义好API接口，基于接口编写测试用例和实现，目标明确 5. 一个个测试用例，就是“摸着石头过河”的石头，没有石头，就过不了河 6. 单元测试用例可以用做软件功能说明书 7. 单元测试用例是用于对付遗留代码的及其重要的组件之一

       1）什么样的步伐合适：测试（对应一行代码清单和少数重构）；刚开始重构要严格遵循步骤，当然也不放过自动化重构工具        2）什么可以不必测试：如果不含业务逻辑，如jsp页面只是显示，业务重点测试（条件部分，循环部分，操作部分，多态性）        3）怎样知道代码有缺点：               1.编写测试，创建的对象数据设置代码很长（对象太大，需要分割）       

软件工程问题及解决       1. 总结归纳需求时，因为用户对需求理解不清，需求的变化，可通过需求管理解决，在沟通中应先澄清概念，定义，范围，背景及沟通的形式（原型和图片比较合适）       2. 重用，更重要的平台级的重用。       3. 有用工具：需求规格（功能和性能指标）记录文档，原型：PENIM，数据库和UML建模程序 测试用例       1. 测试内容：资源打开前是否被使用；异

测试代码不可以完全取代自然语言形式的设计文档呢，原因有三： 其一，测试代码虽然比源代码容易理解，但它仍然是代码，不是所有人都能理解的； 其二，测试代码的宏观表达能力还是不如自然语言或图表； 其三，很多人习惯看文字而不是看代码，彻底改变人的习惯很难。 所以在TDD开发过程中，比较好的形式是自然语言的文档和测试代码相结合，用自然语言的文档做一个够用的设计就行了，这个设计只要详细到模块关系这一级别就足够

  背景 http://www.ibm.com/developerworks/cn/linux/l-tdd/ 一个高效的软件开发过程对软件开发人员来说是至关重要的，决定着开发是痛苦的挣扎，还是不断进步的喜悦。国人对软件蓝领的不屑，对繁琐 冗长的传统开发过程的不耐，使大多数开发人员无所适从。最近兴起的一些软件开发过程相关的技术，提供一些比较高效、实用的软件过程开发方法。其中比较基 础、关键的一个技术

测试驱动开发 测试驱动开发是 敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。 TDD的 基本思路就是通过测试来推动整个开发的进行，但 测试驱动开发并不只是单纯的测试工作，而是把

   自从软件危机的概念被提出以来，人们就在不断地探索解决之道。期间，这些探索者们从其他如硬件、建筑等相对成熟的行业借鉴了不少经验和知识，希望能够以工程化的方法解决软件领域所面对的难题，并提出了“软件工程”这样一个知识框架用以指导实践。但是，几十年过去了，结果表明，“软件工程”为我们带来的对软件开发本身反思方面的作用要远远大于解决软件危机方面的作用。     经历了这么长时间不那么成功的“软件工程

总结： 1、内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。  2、每个具体测试用例都将包括下列详细信息： 用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例的基本元素： 测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。 3、测试用例的设置 按照功能和路径相结合的方式 4、设计测试用例 可

我们知道，测试驱动开发(TDD)的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。再循环进行添加其他功能，直到完全部功能的开发。开发过程如下图，在1~7中循序渐进。 最近，在公司一个支付系统的接口开发中，我按照上述方法进行了一次TDD的开发尝试。具体实现的功能是：解析渠道商返回

classpath，路径列表。告诉java需要加载类的存放位置， java会去搜寻。这种机制实现了动态加载。 java -cp 加载类路径 执行类名   ： 加载类路径可是绝对，也可以相对。     代码重构机制：1，保证没有重复 2，干净，有表现力，能清楚知道意图。 如 一，去除不必要的局部变量（作用：中间传值），将函数结构直接传给下一个函数。 二，代码中不得出现无意常数，或是字符串，这些要放到

TDD 今儿接到一需求如下： 比如一个给定的数字2975，让你去猜。6次机会。如果第一次输入2509，系统会提示 1A2B：其中数字“2”位置猜对&&数字也猜对。称为1A，而“9”和“5”数字猜对了但是位置没有猜对。称为2B。。如果输入2975那么就是4个数字都猜对了并且位置也是对的系统提示4A0B。民间俗称猜数字游戏：百度百科传送门：http://baike.baidu.com/view/358

大家好：   今天的TDD练习又开始了。回头看看上一次留下的任务。 To-Do-List: 猜测数字 输入验证 生成答案 输入次数 输出猜测结果 今天我们把输入验证和随机生成答案搞定。 新建ValidationTest文件。 分析需求：（1）不重复。（2）4位（3）数字。(4)不为空。 按照我们分析出来的4个明确点我们开始写CASE。 注意命名！ [csharp] view plain copy

大家好： 上一篇我剩下的To-Do-List: 猜测数字 输入验证 生成答案 输入次数 输出猜测结果 今天争取全部搞定。 现在我们Guesser、生成答案、输入验证都有了。把它们组装成一起摇身一变成一个Game! 用一个类把这些职责单一的小模块组合起来。我暂且称它为GameManager. 分析剩下的需求。（1）输入6次GameOver.（2）输入合法数字返回猜测结果。（3）游戏结束提示重新开始游

TDD(Test-Driven Development) 测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD得原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。 TDD得基本思路就是通过测试来推动整个开发得进行，但测试

测试：作为动词，它是评估的意思；作为名词，它是导致最终是接受还是不接受的过程。 测试是相互独立的。 测试列表，就跟你生活中记录你的工作计划一样。 测试优先：你应该在什么时候编写测试呢？在你编写要被测试的代码之前。 断言优先：我们什么时候写断言呢？在一开始就写断言。 什么时候开始构建一个系统？从对最终系统的描述开始。 什么时候开始编写一项功能？从希望最终代码通过的测试开始。 什么时候开始编写一个测试