测试驱动开发TDD 笔记

测试驱动开发

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

    TDD的基本思路就是通过测试来推动整个开发得进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。

    TDD的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。

Test-driven development cycle

1.  Add a test

2.  Run all tests and see if the new one fails

3.  Write some code :the code written is only designed to pass the test

4.  Run the automated tests and see them succeed

5.  Refactor code

6.  Rinse and repeat all above

 

One Framework used in TDD is Moq.

If an object has any of the following characteristics, it may be useful to use a mock object in its place:

1.supplies non-deterministic results (e.g. the current time or the current temperature);

2.has states that are difficult to create or reproduce (e.g. a network error);

3.is slow (e.g. a complete database, which would have to be initialized before the test);

4.does not yet exist or may change behavior;

5.would have to include information and methods exclusively for testing purposes (and not for its actual task).

          

TDD的基本过程：

1.  明确当前要完成的功能。可以记录成一个 TODO 列表。

2.  快速完成针对此功能的测试用例编写。

3.  测试代码编译不通过。

4.  编写对应的功能代码。

5.  测试通过。

6.  对代码进行重构，并保证测试通过。

7.  循环完成所有功能的开发。

 
TDD的步骤：

1.在编写产品代码前，先编写它的单元测试代码。没有对应的单元测试代码，不允许作为产品代码被交付。

2.单元测试的测试用例决定了如何编写产品代码。

3.不断的重复运行单元测试用例，并努力让它们成功通过。

4.不断地完善单元测试用例。

 

步骤的一个简单描述：

1.首先确定你要做什么（不是要如何做！！）

2.然后为这个功能（Method）写单元测试例子( Unit Test )

3.编写代码：不用多，也不能少，只需要能实现在Unit Test中的所有实现和能够通过它的Unit Test。

4.运行Unit Test：如果顺利通过，你已经很好的完成了你的任务。如果没通过，修补代码直到能通过Unit Test为止。如果出现在Unit Test中没预先设定的结果，在Unit Test中增加一个Test Case，修补代码直到通过所有的Test Case为止。

   

    每一个测试用例都是单一职责的，因此需要排除外界对他的所有可能的干扰，满足它一切的外界因素条件，模拟给它所需的环境，达到专注于测试该用例的效果。即只有当前测试的类是真实的，其他的都是我们Mock给它的满足它要求的类变量、参数等。

1、复杂对象：Mock一个对象mock；mock .Setup（）.Returns（）设定所需的参数、返回值等环境；

2、普通对象：模拟符合要求的数据

 

 

Example_1：normal steps

//mock an object for filter: context

var context = new Mock<IProcessContext>();

//the real class we want to test

IFilter filter = new NewDeviceFilter();

//scenario 1, verify EventId = 0, DataVersion = 1

//1 arrange(setup)

context.Setup(o => o.ContextObject).Returns(new DeviceProcessContext { EventId = NetEventNewDeivceEventId, DataVersion = 1 });

//2 act

var result = filter.IsMatch(context.Object, null);

//3 assert

Assert.True(result);

 

Example_2 : Mock an object and its out -type argument’s value is “Hello”

 

var currentProcessor = new Mock<IProcessor>();

object process1OutData = " Hello ";

currentProcessor.Setup(o => o.Process(It.IsAny<IProcessContext>(), It.IsAny<object>(), out process1OutData)).Returns(true);

 

Example_3 : the function of returns() can controll the result of Setup():

convert  the result of Function() to lower

mock.Setup(o=>o.Function(It.IsAny< string>())).Returns((string s)=>s.ToLower());

 

Example_4: to inform nextProcessor to execute CallBack() when the function of nextProcessor is Executed

nextProcessor.Setup(o => o.Process(It.IsAny<IProcessContext>(), It.IsAny<object>(), out outData))

.Returns(true)

            .Callback<IProcessContext, object, object>((p, i, o) =>

            {

                 nextRun = true;

             });

 

Example_5: make sure the function always returns true , regardless of the value of argument

notice the function: It.IsAny<>() which purpose is to satisfy the requirements of arguments

filter.Setup(o => o.IsMatch(It.IsAny<IProcessContext>(), It.IsAny<object>())).Returns(true);