[转]Unit Test 原则

软件开发四个变量
Cost
Time
Quality
Scope
我们能控制什么？

最基本的目标
健壮，稳定——沙滩上的玻璃宫殿
各种各样不可预料的错误
一点点变化马上瘫痪
容易修改和扩展——生活就像一团麻
修改涉及的内容漫无边际，而且不可预知
修改的代价超过忍受的范围

基本方法&原则
简单
最小耦合，最少依赖
去掉重复
封装
抽象
对修改封闭，对扩展开放
易重用
易测试

祖传秘方
祖传秘方——代码

Discovering Better Code
Unit Test
Refactoring
Principles & Practice

Unit Test

Why: Unit Test
确认你自己是否确实理解你作要做的
验证程序所作的确实是你想要的
快速定位bug
减少回归测试
Collateral damage
编码前的设计
易测试的代码
可执行的文档
给你勇气

Excuses For Not Testing
It takes too much time to write the tests
It takes too long to run the tests
It's not my job to test my code
I'm being paid to write code, not to write tests
I feel guilty about putting testers and QA staff out of work

What to Test: The Right-BICEP
Right: Are the results right
B: Are all the boundary conditions CORRECT
I: Can you check inverse relationships
C: Can you cross-check results using other means
E: Can you force error conditions to happen
P: Are performance characteristics within bounds

Are the Results Right
最基本的测试形式
怎样判断结果是正确的
用最简洁的形式给出结果 Pass or No

Boundary Conditions
有一半的错误来自Boundary
需要特别加强对Boundary的测试
寻找Boundary

Boundary: CORRECT
Conformance: Does the value conform to an expected format ?
Ordering: Is the set of values ordered or unordered as appropriate ?
Range: Is the value within reasonable minimum and maximum values ?
Reference: Does the code reference anything external that isn't under direct control of the code itself?
Existence: Does the value exist (non-null, nonzero, etc.) ?
Cardinality: Are there exactly enough values?
Time：(absolute and relative): Is everything happening in order? At the right time? In time?

Check Inverse Relationships
用反向逻辑来验证结果
为了避免干扰，采用不同的算法

Cross-check Using Other Means
用其他的算法来检验
用简单的，稳定的算法来检验高级算法

Force Error Conditions
错误发生，代码是不是能正确地处理
可以预见的错误：可以预见的都不应算是Exception
不可预料或者不需要特别处理的错误
参数，前置条件，环境，硬件，配置等等

Performance Characteristics
对性能作测量
不要最后再考虑性能

Test基本原则
尽早测试，持续测试
自动化
相互隔离
不改变系统原来的状态
永远不要在正式运行的系统运行测试代码

Test基本原则
简单，有效
明确：直接输出测试通过与否
针对最大风险的代码
需要所有的测试通过，而不只是最新的一个

测试相关技巧
Test Framework
输入输出文件
Mock Object

Mock Object
Mock Object和要测试的对象有同样的Interface
Mock Object的用法

Problems
Test an abstract class
Test private method
Multi-threaded environment
Test GUI

数据库测试
Enterprise Services
Setup & Teardown script
Transaction
Mock the DB layer
DbUnit
依赖DAL的是实现形式

我们的工具介绍
NUnit + NUnitAsp
Nunit.Framework.TestAttribute
NUnit.Framework.Assert
Nunit.Framework.ExpectedExceptionAttribute
NUnit.Framework.IgnoreAttribute
Nunit.Framework.SetUpAttribute
Nunit.Framework.TearDownAttribute

Where to Put Test Code
同一文件
同一Namespace
平行的Namespace
单独的Project

我们需要做的
习惯
一份Check List
匍匐前进也是前进

一些资源
《Preventing Bugs with Unit Testing》http://www.codertodeveloper.com/4327c05.pdf
《Advanced Unit Testing》 http://www.codeproject.com/csharp/autp1.asp
MbUnit http://mbunit.tigris.org
.NET MockObjects http://sourceforge.net/projects/dotnetmock
nunit2report http://nunit2report.sourceforge.net/
NCover http://ncover.sourceforge.net/
NMock http://nmock.truemesh.com/
NUnitAddin http://sourceforge.net/projects/nunitaddin

更进一步：测试驱动开发
不是Unit Test驱动
TDD基于需求驱动的
TDD围绕着具体的功能进行的，而不是围绕某种结构进行。
另一份文档单独讨论

Reference
《The Pragmatic Programmer》
《Refactoring : Improving the Design of Existing Code》
《Pragmatic Unit Testing》