《Architecting Modern Java EE App

这本书陆陆续续读了比较久了，前面章节先不谈，先谈谈Testing这一章。

测试的必要性：需要再次强调，拥有好的测试是快速开发的基础。

好的测试应该包含的特征

• 可预测性：相同的代码必须产生相同的结果。这就需要我们的测试排除环境，时间，随机数字之类的影响。
• 封闭性：测试之间不能相互依赖。测试数据自给自足。
• 可靠性：通过的说明代码的确通过了宣称测试的东西。
• 快速执行: 随着测试的增多这一点越来越重要。
• 自动化：人容易出错，反复重复的事情交给机器来干。
• 可维护性:对于测试代码要像生产代码一样对待。快速的需求变化=》快速的代码变化=》快速的测试变化。没有可维护性的测试，无法满足快速开发的需求。

测试的范围
测试可以粗略分为代码级别的测试和应用级别的测试。

• 单元测试：代码级别，测试一个或多个类。
• 组件测试：代码级别，测试多个单元。
• 集成测试：这是个含义有些模糊的词。作者在这里还是把作为类似组件测试的代码级别的测试，但是测试需要在某个测试容器（但不是真正的服务器）中来运行，这里的集成更多是指技术意义上的集成。这些需要测试的集成方面包括比如：CDI的配置是否正确，OR Mapping的配置是否正确，全局event是否触发，等等。
• 系统测试：端对端的测试，覆盖所有逻辑（业务的，技术的）。这里的前端未必是UI，比如某个接口的测试，他的端对端测试就不存在UI部分，但也属于系统测试。
• 性能测试，压力测试，和上面的测试都不同，测试非功能性部分。

测试的实现

• 单元测试：用JUnit， Mockito等工具
• 组件测试：组件测试用来测试多个类之间的协作。由于还是代码级别的业务逻辑的测试，一些底层依赖（如DB访问）需要被mock掉。如何统一生成，管理并替换mock对象，是组件测试的难点所在。书中提出一种方式是通过继承，比如我们原来想要测试对象A，我们可以写一个新的类B来继承A，B中mock掉了A中所有底层不需要测试的部分，我们的测试只和B打交道。通过CDI框架比如Spring，也能很好得管理mock，但是初始化Spring容器很花时间，所以不是太推荐。
• 集成测试：代码级别的集成测试目的是快速测试技术方面的集成，而不需要将代码实际发布到服务器上。这需要我们使用嵌入式的容器。可以用CDI-Unit或者Arquillian这种功能强大的Runner ，它可以模拟J2EE容器环境。

以上测试都是代码级别的测试，之后作者专门用一小章来探讨系统测试。

系统测试
系统测试是把代码发布到类产品环境来进行测试。如果依赖于外部系统的话，还需要mock这些外部系统来实现测试的可预测性，这是以前我们的测试不曾注意的。对于DB是否属于外部系统需要被mock掉，要看情况而定。
对于外部系统的Mock，如果是http请求，可以使用WireMock之类的mock http server，并通过Kubernetes之类的容器管理工具来统一管理。

性能测试
性能测试通过用机器模仿用户行为并收集一些关键值：响应时间，错误率等，来获取对系统的insight。压力测试则是获取服务器最大能承受的访问量等数据。性能测试和其他测试不一样，不是简单的通过不通过的测试，而是通过持续收集性能测试的数据，我们可以发现系统中不同功能的性能的变化趋势，在影响客户体验之前能及时发现问题。
常用工具Gatling, Apache JMeter

维护测试
难以维护的测试屡见不鲜。开发者往往不把测试当做产品代码的一部分来对待，导致写得随意，直接的现象就是测试缺乏抽象，写出的一个巨大的测试方法里实现了各种功能，而没有抽象出方法和类。
系统测试可以用BDD的风格来写，从而达到比较好的抽象层次。这时候可以用一些支持BBT(Behavior Based Testing )或者叫SBT(Specification Based Testing)语法的测试框架，如Cucumber-JVM, FitNesse。还提到了可以自定义assertde AssertJ, 基于SBT的Spock Testing Framework(使用Groovy语言）.