Neo的专栏

在做单元测试的时候，我们会发现我们要测试的方法会引用很多外部依赖的对象，比如：（发送邮件，网络通讯，记录Log, 文件系统 之类的）。 而我们没法控制这些外部依赖的对象。  为了解决这个问题，我们需要用到Stub和Mock来模拟这些外部依赖的对象,从而控制它们 阅读目录实例设计测试用例什么是外部依赖Stub和Mock的相同处Stub和Mock的区别良好的产品代码才能单元测试

摘要：所谓TDD简单地说就是以下两个步骤：确保所有的需求都能被照顾到；在代码不断增加和重构的过程中，可以检查所有的功能是否正确。本文我们一起来看下关于TDD的五大误区。TDD（全称Test Driven Development）测试驱动开发，是一种软件开发的流程，其由敏捷的“极限编程”引入。其开发过程是从功能需求的测试用例开始，先添加一个测试用例，然后运行所有的测试用例看看有没

测试驱动开发是一种先开发测试的先进技术，即你在编写足够的产品代码用于测试和重构之前就编写测试。测试驱动开发的初衷是什么呢？一种观点是TDD是一种规范而不是校验。就是说它是在你编码之前就惯穿设计的一种思考。另一个观点是TDD是一种编码技术，就像Ron Jeffries喜欢说的那样TDD可用来编写干净的可工作的代码。尽管我把决定权留给读者，但我想以上两点各有其道理。目录一、 什么是TDD？..

单元测试和设计模式在重构中的应用本文结合一个事例谈谈设计模式在重构中的应用。在重构过程中，单元测试发挥了很大的作用。这是一个报表系统，每天将公司分散在各处的数据收集产生各种报表。本文只拿出系统的数据访问层面做例子。 系统需要处理的数据源比较多，系统中建立了一个Connection Pool对这些数据源进行管理，外界使用一个数据源的名称，从Connection Pool中得到相应的数

TDD这个概念出现至少也有两年多了, 在大家刚接触它时候, 几乎没人不拍手鼓掌, 测试驱动的概念确实可以为我们带来很多的好处. 泡泡在前不久写了一篇很不错的TDD的文章, 可是我还是忍不住在他的评论中说到这篇文章有点”老”. 确实,同样的概念在书中, 在大家的口中已经被说烂了. 但是TDD真正给我们带来什么呢? 有多少人在用TDD呢? 为什么这么好的技术到了应用中就被人们”抛弃”了呢?(注:

刚才看了idior的一篇文章：Enterprise Test Driven Develop。看后有一些感想，在这里写下这篇文章，讲讲我对这个问题的看法：自动化的单元测试应该测什么。最近有朋友提出意见，觉得我写的文章比较空洞，写的很长，但是很不实在。可能原因是这样的：代码太少了。今天就从一段代码开始吧，这段代码描述电信营业系统中的缴费开机的过程：User user = User.

实例——在编程过程中进行单元测试这是一个真枪实弹的例子，如何在编程过程中进行单元测试。本文以一个图书馆的书籍管理系统作为例子，讲述一个单元测试——编码的循环过程。这里只讲述一个独立画面的编写。画面的编码分两个部分，业务数据部分和界面表示部分。先介绍业务数据部分的编写。下面具体的描述单元测试是如何融入到设计和编码的过程当中的，单元测试驱动着编码的过程，可以说，编码的目的就在于

原文版本:4.0, April 2007原文作者:Geotechnical Software Services原文链接:http://geosoft.no/development/unittesting.html翻译日期:2009 年 6 月译者 ( brantyoung ) 前言:项目主页:G

1  A类依赖B 类，可以把B类提取成IB接口，解除AB 之间的依赖关系。     通过创建实现了IB接口的BStub 装代码，可以模拟B类进行测试。   这是针对接口编程的典型。适合构造代价大，变化多的情况。应用示例如下：   a.上层与下层之间的设计，比如业务层依赖数据访问层。   b. B类是一个复杂对象。 比如 发送邮件，连接网络，调用物理硬件接口等

前段时间有不少朋友发文讨论TDD引起了比较热烈的反响。我学习和实践TDD有近一年时间了，也希望把自己对TDD的理解拿出来讨论分享。本文讲讨论TDD的精髓和盲区，并希望引导TDD的初学者正确认识“TDD可以驱动得出更好的设计”这一著名论断。TDD的精髓提到TDD，最先浮现在我们脑海中的多半是这幅经典的迭代流程图：不过，我认为这幅图的作用只在于与传统开发流程形成对比，更多的是一种形式上

1、自然输入　　自然输入是指对底层函数的正常调用即可获得的内部输入。代码一中Compare()函数内，int a1 = GetArea(r)；可以自然取得外接正方形的面积。如果外接正方形面积a1要得到某个预期的值，要传递合适的半径r，半径r称为间接输入。间接输入需根据自然输入及底层函数的功能来倒推，要获得符合预期的自然输入有三个条件：一是底层函数存在，二是底层函数正确，三是间接输入正确。很

想当年毕业设计就是测试驱动开发，所以从刚入行开始就对单元测试、测试驱动开发有比较深入的认识，刚开始一直作为敏捷开发的忠实粉丝。但是几年工作下来，我开始对单元测试持矛盾的态度：单元测试当然是一种很好的创举，但是具体使用当中，它却经常会产生种种负作用，使开发人员望而生畏。这当然不是因为单元测试这一技术或思想本身的问题，而是实践这一思想的人的问题。 当前很多公司使用单元测试的怪现象：