新的挑战
  微服务和传统的单块应用相比,在测试策略上,会有一些不太一样的地方。简单来说,在微服务架构中,测试的层次变得更多,而且对环境的搭建要求更高。比如对单块应用,在一个机器上可以setup出所有的依赖,但是在微服务场景下,由于依赖的服务往往很多,要搭建一个完整的环境非常困难,这对团队的DevOps的能力也有比较高的要求。
  相对于单块来说,微服务架构具有以下特点:
  · 每个微服务在物理上分属不同进程
  · 服务间往往通过RESTful来集成
  · 多语言,多数据库,多运行时
  · 网络的不可靠特性
  · 不同的团队和交付周期
  上述的这些微服务环境的特点,决定了在微服务场景中进行测试自然会面临的一些挑战:
  · 服务间依赖关系复杂
  · 需要为每个不同语言,不同数据库的服务搭建各自的环境
  · 端到端测试时,环境准备复杂
  · 网络的不可靠会导致测试套件的不稳定
  · 团队之间的沟通成本
  测试的分层
  相比于常见的三层测试金字塔,在微服务场景下,这个层次可以被扩展为5层(如果将UI测试单独抽取出来,可以分为六层)。
  · 单元测试
  · 集成测试
  · 组件测试
  · 契约测试
  · 端到端测试

  和测试金字塔的基本原则相同:
  1、越往上,越接近业务/终用户;越往下,越接近开发
  2、越往上,测试用例越少
  3、越往上,测试成本越高(越耗时,失败时的信息越模糊,越难跟踪)
  单元测试
  单元测试,即每个微服务内部,对于领域对象,领域逻辑的测试。它的隔离性比较高,无需其他依赖,执行速度较快。
  对于业务规则:
  1、商用软件需要License才可以使用,License有时间限制
  2、需要License的软件在到期之前,系统需要发出告警

  上面这个例子是一个非常典型的单元测试,它和其他组件基本上没有依赖。即使要测试的对象对其他类有依赖,我们会Stub/Mock的手段来将这些依赖消除,比如使用mockito/PowerMock。
  集成测试
  系统内模块(一个模块对其周边的依赖项)间的集成,系统间的集成都可以归类为集成测试。比如
  · 数据库访问模块与数据库的集成
  · 对外部service依赖的测试,比如对第三方支付,通知等服务的集成
  集成测试强调模块和外部的交互的验证,在集成测试时,通常会涉及到外部的组件,比如数据库,第三方服务。这时候需要尽可能真实的去与外部组件进行交互,比如使用和真实环境相同类型的数据库,采用独立模式(Standalone)的WireMock来启动外部依赖的RESTful系统。
  通常会用来做模拟外部依赖工具包括:
  · WireMock
  · mountebank
  其中,mountbank还支持Socket级别的Mock,可以在非HTTP协议的场景中使用。