Test Case 作用

1. 检查你的产品代码是否按预期工作, 这由函数体来完成

2. 表达你的预期,让阅读代码的人知道你的产品能够干什么,如何使用, 甚至如何设计的;这除了函数体的assert语句外,Test case的名字更是重要的手段

3.保证重构不出错

4.展示API的用法, 最好的Quick Start

5.Domain知识的载体, 最好的文档

6……

 

Test Case的命名

1, 如果Domain比较简单,  比如上面的Calculator, 每个人都很清楚, 你就不需要再通过测试用例的名字罗里罗嗦了, 这时候可以选用表达实现的名字

2, 如果Domain比较复杂, 进入项目的新人不一定了解, 这时候你的测试用例的名字就是最好的领域知识

Test Case的装配
1. 如果一个对象很容易用一两句话装配, 一般可以在每个测试用例里就近创建它

2. 如果初始化一个对象很复杂, 要不少代码, 就写一个函数来做初始化, 然后在每个测试用例里就近调用它

3. setUp()里主要是一些对外部依赖环境的设置.

Mocks Vs. Stubs

1. Stubs 属于 State Based Test方法的实现方式 .他测试的是方法的结果..对其中的过程并不关心.

2. Mocks 属于 Interaction Based Test/ Behaviour verification Test的实现方式 .他还要测试方法的过程.

3. <<Mocks Aren't Stubs>>

4. Stubs 的注意事项:
     不要包含任何逻辑;
     强迫你重新考虑你的设计 (其实这几乎是任何高质量的测试用例都能带来的)
        1), 调用链
              如果调用链很长就需要写很多Stubs类.
        2), 针对接口编程

5.动态代理Stub(zz)

  这是介于静态手写Stub和完全的MockObject之间的一种方式, 基本上用它来简化Stub的编写, 所以本质上还是属于 Stub, 尽管Mock Object可能是用动态代理实现的

动态代理Stub相比静态手写Stub的主要好处就是不需要Stub实现所有API, 只要 在invoke之类的函数中针对测试用例用到的函数进行处理就可以了

还有一种用反射实现的代理, 可以复用现有的Stub, 不需要这些Stub实现什么接口, 只需要函数签名一致即可

6. Mock Object
   1)Mock则更多的关注于Mock 对象的某个方法是否被调用(行为是否发生), 以及调用时的参数和返回值.
  
   2)重构会破坏测试用例(包含Mock Object), 即使你的重构是正确的

   3)体现在那些紧凑的API上, 即单一API调用, 根据不同参数返回不同结果.不适合用Mock Object.最好使用真实数据.
 
   4)Stub 不到万不得以不用, Mock 能用则用.
  
Don’t Ask, Tell

   Ask 带来的坏处:

      1.   破坏对象的封装性, 你不得不暴露很多的属性供别人Ask.

      2.   容易使得一些对象过于复杂(会计部), 而一些对象(员工)又过于简单, 甚至成为了仅仅包含数据的”哑”对象.

   Tell 带来的好处:

      1.  更多的考虑责任分配的合理性, 方法涉及的数据在哪里方法就应该在哪里. 这样对象的内聚性就大大加强了.

      2.  增强了对象的封装性, 对象不必暴露更多的属性.

      3.  可以充分发挥面向对象的特性,比如多态, 减少”哑”对象从而获得更强的可维护性,扩展性以及面对变化的能力.