Junit实战学习笔记

理解单元测试框架

1.每个单元测试都必须独立于其他所有单元测试而运行；

2.框架应该以单个测试未单位来检测和报告错误；

3.应该易于定义要运行哪些单元测试。

fixtures

@Before 

@After

@BeforeClass 

@AfterClass

@Test

@Ignore

Junit断言方法

1. assertArrayEquals("message", A, B)  --断言A数组和B数组相等

2. assertEauals("message", A, B)  --断言A对象和B对象相等

3. assertSame("message", A, B)  --断言A对象和B对象相同

4. assertTrue("message", A)    --断言A条件为真

5. assertNotNull("message", A)  --断言A对象不为null

Junit技巧

1.运行参数化测试

2.测试异常处理

3.超时测试

4.引入Hamcrest匹配器

5.Cobertura --与Junit集成的代码覆盖率测试工具

6.使用stub进行粗粒度测试 --使用嵌入式Web服务器（Jetty服务器），可以嵌入测试用例类的Java Web服务器；替换Java的HttpURLConnection类是一个更轻量级的解决方案。

7.使用mock objectcs进行测试

三种单元测试

1.逻辑单元测试

2.集成单元测试

3.功能单元测试

最佳实践：

0.一次只能单元测试一个对象

1.在assert调用中解释失败的原因

2.让测试改善你的代码

3.总是为跳过测试说明原因

4.相同的包，分离的目录

5. 首先编写失败的测试

6. 持续回归测试 --使用旧的测试防止新的变化是一种回归测试的形式。确保回归测试进行的最好方法是将你的测试集自动化。

7.不要在mock objects中写入业务逻辑

8. 只测试那些可能出错的代码

9. 创建EasyMock对象

测试驱动开发（TDD）

流程：测试，编码，重构，（重复），提交

核心原则：1. 在编写新代码之前编写一个失败的自动测试；

      2. 消除重复

测试类型

三种单元测试

1.逻辑单元测试

2.集成单元测试

3.功能单元测试

mock objects实践--揭开mocks的神秘面纱

1.mocks并不实现任何逻辑，它们只是提供了一种使测试能够控制仿造类的所有业务逻辑方法行为的方法的空壳。

2.mock框架：EasyMock，Mockito，MockPower，Jmockit

学习笔记：

1. 请记住，进行成组单元测试的好处之一就是鼓励你勇敢的进行重构--单元测试是防止衰退的卫士。如果你的测试粒度比较大，那么一旦重构引入了一个bug， 就有一系列的测试会因此而失败；结果就是测试会告诉你出现了一个错误，但是并不会告诉你这个错误在什么地方；而使用细粒度测试，受到潜在影响的测试就会比较少，而且测试会提提供精确的信息，指出错误的确切原因。

2. 实际上，单元测试是对运行时代码的最好运用，应该同其他运用同等看待。如果你的代码不太灵活，以致在测试中无法使用，那么你就应该对它进行修改。

3. 一个有效的设计策略就是，将直接业务逻辑外的其他对象传递给逻辑内的对象。外围对象选择应该由在调用链上更高层次的某个人控制。最终，当你沿着调用层向上移动时，使用一个给定的记录器或者配置的决定权就应该推给最高层次的人。这种策略可以提供更好的代码灵活性以及应付变化的能力。

4. mock objects的技法，可以让你隔离于其他域对象以及环境针对代码进行单元测试。当涉及写细粒度单元测试时，一个主要的障碍就是从执行环境中抽象出来。大多数情况下，编写mock object测试有一个正面的副作用：它迫使你重写部分待测试的代码。

5. 测试驱动开发（TTD）就是提倡在编写代码之前先编写测试。使用TDD，你就不再需要为了可以进行单元测试而重构代码：所编写的代码已经是可以测试的了。可参考Kent Beck的著作《Test Driven Development: By Example》