标签:单元测试
单元测试属于白盒测试,它是所有测试的第一个环节,也是最重要的一个环节。
它主要是针对一个类的public的方法来做测试。
编写单元测试是一种验证类功能的行为,和优化设计的重要手段,因此它是程序员的工作。
编写单元测试的过程
从测试列表中取出一个测试case
定义一个测试方法
public void Test_{MethodName}_{InputParameter}_{Expectation}
{
//准备测试数据
//执行被测试方法
//验证期望结果
}
准备测试数据
这个主要包括构建被测试方法的参数,模拟被测试方法调用到的依赖对象,并通过set属性给被测试对象赋值等
执行被测试的方法
验证期望结果
对被测试方法进行断言,对模拟对象的被调用情况进行断言
这里是一个具体例子:
[Test]
public void Test_Read_SingleKey_Successful()
{
MemcachedClient memcachedClient = schoonerStorage.MemcacheClient.CacheClient;
//准备测试数据
string businessKey = "100_1";
byte[] returnData = new byte[]{1,23,12,1};
Expect.Call(memcachedClient.Get(businessKey)).Return(returnData);
memcachedClient.Replay();
//执行被测试方法
byte[] actualData = schoonerStorage.Read(businessKey);
//验证期望结果
Assert.AreEqual(returnData, actualData);
memcachedClient.VerifyAllExpectations();
}
单元测试命名规范
存放测试类的工程命名为{被测试个工程名}.UnitTest
测试类保持和被测试工程一样的目录结构或包结构,并且命名为{被测试类}Test
测试类中的测试用例采用Test_{被测试方法}_{测试点}_{期望的测试结果}的命名方式
其中{测试点}可以是参数类型,参数边界值等等
单元测试注意事项
隔离测试用例的依赖性(目前单元测试工具如xUnit一般会保证这一点)
测试用例要覆盖到正常工作流程,异常工作流,输入参数的边界值等
测试用例的粒度不能太大,如果一个测试用例要验证的点太多,看能不能拆成更小的用例
测试驱动开发(TDD)
TDD是一种全新的开发模式,其迫使开发人员先编写单元测试,再编写产品代码。其过程如下:
以特性(feature)为单位,抽象出该特性涉及的相关类和接口,以及它们之间的依赖关系。
针对类编写测试用例(首先在测试类的头部列出你要测试列表,然后依照一定的优先级来编写测试用例)
执行测试用例,用例没有通过
编写产品代码
执行测试用例,用例通过
重复3-5步,完成整个类的测试用例
对产品代码或测试用例进行重构消除重复设计,并优化代码结构
确保所有测试用例都通过
提交代码到产品库
CI服务器对所以单元测试进行集成测试
如果有任何测试用例失败,在开发新的产品代码之前,优先修复失败的测试用例
TDD有助于开发人员站在使用者角度来开发产品代码,始终保持产品代码的简洁可用。
标签:单元测试
原文地址:http://13713878410.blog.51cto.com/9096807/1567206