每个测试都应该是一座孤岛
这本书的定位是Junit的入门书籍，我用Junit差不多有五年的时间了,因此大部分的概念对我而言都并不陌生。我所在的项目组对产品代码覆盖率要求非常高，要写非常多测试代码来验证功能。
大概用了一下午的时间，快速的翻了翻这本书，记了些笔记。总体感觉大概就是可以做junit的user guild了。
单元测试的目的：
--------------------------------------------------------------------------------
执行单元测试，是为了证明某段代码的行为确实和开发者期待的一样，又可具体为：
1> 它的行为和我的期望一致吗？
2〉它的行为始终和我的期望一致吗？
注：“始终”反映出：产品代码是否稳定？测试代码是否具有可重复性？
单元测试说明了我的意图了吗？
--------------------------------------------------------------------------------
程序员写测试代码的过程，也是理解需求的过程。单元测试一般都是白盒测试，需要程序员重新审视自己的代码是否满足需求，也会进一步审视自己的代码是否优秀以方便测试。如果是由其他人写单元测试代码，起到的是一个代码审查和knowledge sharing的作用。如果使用的是敏捷组织所倡导的测试驱动开发，会促使程序员写出结构更简单更方便测试的代码。
需要测试哪些内容？Right-BICEP
--------------------------------------------------------------------------------
Right 测试的结果是否正确/ Boundary Condition 边界条件/ Inverse relation 反转关系/ Cross check 交叉测试/ Exception,Error/ Performance
有哪些边界条件？ CORRECT：
--------------------------------------------------------------------------------
Conformity一致性/ Ordering顺序性/ Range区间性/ Reference依赖性/ Existence存在性/ Cardinality基数性/ Time时间正确性
Mock
--------------------------------------------------------------------------------
Mock体现了接口类型使用的好处。对于方法的使用，引用处应该使用类的接口类型，即抽象类型而不是实际类型。Mock对象和被测试对象需要使用同一接口，因此在使用的时候，可以使用mock对象来替换真实对象。非常适合使用在当真实对象不宜/不易生成或者不稳定的情况。
EasyMock是基于mock技术的一套类库。
好的测试品质 A-TRIP：
--------------------------------------------------------------------------------
Automatic 自动化：调用测试自动化/检查结果自动化。可以引入持续集成工具来进行。
Thorough 彻底的：测试代码对产品代码的覆盖率要比较高。可以用Clover等工具衡量。
Repeatable 可重复的：每次测试的结果都一样。要求测试代码不依赖于不能控制的东西，如环境。必要时可以引入Mock对象。
Independent 独立的：每个测试都应该是一座孤岛。测试应当简洁精炼，针对性强。测试之间应该互相不影响，可以任何时候以任意顺序运行测试用例。
Professional 专业的：要写好的测试代码。任何针对设计的普遍规则，如DRY，解耦等，同样适用于UT。如果要达到比较高的覆盖率，测试代码会很多，因此需要保持跟产品代码一样的专业程度，保持简洁精炼，设计良好且重构充分。
方法的参数是否需要验证？
--------------------------------------------------------------------------------
这时一个开放性问题。如果方法定义处和使用处都做了验证，对于很多不愿意放太多时间在测试上的团队而言，是浪费时间和精力的。而且这么做也违反了DRY原则。最坏情况是没人做检查，这不符合良好测试的彻底性品质。
因为UT是针对方法级别的测试，建议是如果被测试的方法做了检查，那应该有相应的测试代码去测试这个检查。如果被测试方法未做检查，那我们有理由相信，在某个入口处应该保证了参数的合法性，此时测试代码可以把重点放在功能上。
测试代码应该放哪？
--------------------------------------------------------------------------------
作者给出了三个建议：
1〉和源代码同一目录。缺点是测试代码到处都是，不易管理，而且如果最后发布的产品不需要包含测试代码，会给构建和发布最后产品的工作增加复杂度；
2〉在当前被测试代码的子目录。缺点是不在同一个package，不能访问protected成员；
3〉并行树。测试类和产品代码在同一个包中，但位于不同的源码树。需要确保两棵树的根都在classpath中。这下测试代码是真的跑远了。
第三种方法好。既解决了产品代码应该和测试代码在同一个包中以确保protected成员能被访问的问题，也解决了两者实际路径应该分开的问题。
--------------------------------------------------------------------------------
在实际使用的过程中，可以在给Junit传参数指定要运行的testcase，否则：
如果测试类定义了suit方法，则会运行所有包含在该方法内的testcase；
否则Junit将使用反射机制来发现testXXXX方法。
Junit的suit()提供了自定义测试集合的功能，可以覆写。
assertTrue(true) // 我预计流程每次都会来到这个地方
注：这种写法可读性不是很强，至少它看上去怪怪的。assert一个经过该流程的变量会好一些。
大概用了一下午的时间，快速的翻了翻这本书，记了些笔记。总体感觉大概就是可以做junit的user guild了。
单元测试的目的：
--------------------------------------------------------------------------------
执行单元测试，是为了证明某段代码的行为确实和开发者期待的一样，又可具体为：
1> 它的行为和我的期望一致吗？
2〉它的行为始终和我的期望一致吗？
注：“始终”反映出：产品代码是否稳定？测试代码是否具有可重复性？
单元测试说明了我的意图了吗？
--------------------------------------------------------------------------------
程序员写测试代码的过程，也是理解需求的过程。单元测试一般都是白盒测试，需要程序员重新审视自己的代码是否满足需求，也会进一步审视自己的代码是否优秀以方便测试。如果是由其他人写单元测试代码，起到的是一个代码审查和knowledge sharing的作用。如果使用的是敏捷组织所倡导的测试驱动开发，会促使程序员写出结构更简单更方便测试的代码。
需要测试哪些内容？Right-BICEP
--------------------------------------------------------------------------------
Right 测试的结果是否正确/ Boundary Condition 边界条件/ Inverse relation 反转关系/ Cross check 交叉测试/ Exception,Error/ Performance
有哪些边界条件？ CORRECT：
--------------------------------------------------------------------------------
Conformity一致性/ Ordering顺序性/ Range区间性/ Reference依赖性/ Existence存在性/ Cardinality基数性/ Time时间正确性
Mock
--------------------------------------------------------------------------------
Mock体现了接口类型使用的好处。对于方法的使用，引用处应该使用类的接口类型，即抽象类型而不是实际类型。Mock对象和被测试对象需要使用同一接口，因此在使用的时候，可以使用mock对象来替换真实对象。非常适合使用在当真实对象不宜/不易生成或者不稳定的情况。
EasyMock是基于mock技术的一套类库。
好的测试品质 A-TRIP：
--------------------------------------------------------------------------------
Automatic 自动化：调用测试自动化/检查结果自动化。可以引入持续集成工具来进行。
Thorough 彻底的：测试代码对产品代码的覆盖率要比较高。可以用Clover等工具衡量。
Repeatable 可重复的：每次测试的结果都一样。要求测试代码不依赖于不能控制的东西，如环境。必要时可以引入Mock对象。
Independent 独立的：每个测试都应该是一座孤岛。测试应当简洁精炼，针对性强。测试之间应该互相不影响，可以任何时候以任意顺序运行测试用例。
Professional 专业的：要写好的测试代码。任何针对设计的普遍规则，如DRY，解耦等，同样适用于UT。如果要达到比较高的覆盖率，测试代码会很多，因此需要保持跟产品代码一样的专业程度，保持简洁精炼，设计良好且重构充分。
方法的参数是否需要验证？
--------------------------------------------------------------------------------
这时一个开放性问题。如果方法定义处和使用处都做了验证，对于很多不愿意放太多时间在测试上的团队而言，是浪费时间和精力的。而且这么做也违反了DRY原则。最坏情况是没人做检查，这不符合良好测试的彻底性品质。
因为UT是针对方法级别的测试，建议是如果被测试的方法做了检查，那应该有相应的测试代码去测试这个检查。如果被测试方法未做检查，那我们有理由相信，在某个入口处应该保证了参数的合法性，此时测试代码可以把重点放在功能上。
测试代码应该放哪？
--------------------------------------------------------------------------------
作者给出了三个建议：
1〉和源代码同一目录。缺点是测试代码到处都是，不易管理，而且如果最后发布的产品不需要包含测试代码，会给构建和发布最后产品的工作增加复杂度；
2〉在当前被测试代码的子目录。缺点是不在同一个package，不能访问protected成员；
3〉并行树。测试类和产品代码在同一个包中，但位于不同的源码树。需要确保两棵树的根都在classpath中。这下测试代码是真的跑远了。
第三种方法好。既解决了产品代码应该和测试代码在同一个包中以确保protected成员能被访问的问题，也解决了两者实际路径应该分开的问题。
--------------------------------------------------------------------------------
在实际使用的过程中，可以在给Junit传参数指定要运行的testcase，否则：
如果测试类定义了suit方法，则会运行所有包含在该方法内的testcase；
否则Junit将使用反射机制来发现testXXXX方法。
Junit的suit()提供了自定义测试集合的功能，可以覆写。
assertTrue(true) // 我预计流程每次都会来到这个地方
注：这种写法可读性不是很强，至少它看上去怪怪的。assert一个经过该流程的变量会好一些。
有关键情节透露
