单元测试笔记

1. 单元测试
     不：
         1. 不测试输入输出相关的代码，比如数据库操作、文件操作、网络IO等
         2. 不需要上下文。仅测最小可执行单元的逻辑
         3. 不是冒烟测试或者功能测试。
         4. 不依赖于环境。不需提前准备程序运行环境，如数据库等，仅需基本程序编译运行环境及框架支持。
         （上述测试也是重要并不可或缺的）
        
     是：对程序中最小可执行单元进行独立测试
    
2. 不要用Main函数测试你的程序，因为：
     a. 不可复用
     b. 不方便维护。测试完后如何处理Main？
     c. 需要测试的代码较多时，不能自动化，结果不够直观
    
3. 最佳实践：
     a. 三部曲：Arrange,Act,Assert -- 准备数据，执行测试，断言
     b. 一个测试方法一个断言 -- 多个断言，测试失败，到底是哪个断言失败？
     c. 保持多个测试方法间的独立 -- 依赖导致失败传递
     d. 不要将看似公用的测试方法抽象成抽象类 -- 保持“单元”的纯粹性
     e. 以单元测试促进你的设计 -- 当准备数据变得很复杂，当测试代码变得很难写，回头重新检查你的代码设计
     f. 将单元测试加入持续集成
     g. 保证测试代码和实际代码包路径相同 -- 方便测试package-private方法/快速定位测试代码
     h. 不要在单元测试代码中打印任何内容 -- 没用
     i. 不要通过构造函数初始化测试用例，使用@Before
     j. 异常的测试 -- 使用并慎用expected @Test(expected = IndexOutOfBoundsException.class)
     k. 不要试图通过A类对B类进行单元测试 -- A类的变换可能导致测试的失效
     l. 使用带String参数的assert方法，清晰表明测试案例失败的原因，快速定位