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方法，清晰表明测试案例失败的原因，快速定位