[转]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》