微服务中的测试
新的挑战 微服务和传统的单块应用相比，在测试策略上，会有一些不太一样的地方。简单来说，在微服务架构中，测试的层次变得更多，而且对环境的搭建要求更高。比如对单块应用，在一个机器上就可以setup出所有的依赖，但是在微服务场景下，由于依赖的服务往往很多，要搭建一个完整的环境非常困难，这对团队的DevOps的能力也有比较高的要求。 相对于单块来说，微服务架构具有以下特点： 每个微服务在物理上分属不同进程 服务间往往通过RESTful来集成 多语言，多数据库，多运行时 网络的不可靠特性 不同的团队和交付周期 上述的这些微服务环境的特点，决定了在微服务场景中进行测试自然会面临的一些挑战： 服务间依赖关系复杂 需要为每个不同语言，不同数据库的服务搭建各自的环境 端到端测试时，环境准备复杂 网络的不可靠会导致测试套件的不稳定 团队之间的沟通成本 测试的分层 相比于常见的三层测试金字塔，在微服务场景下，这个层次可以被扩展为5层（如果将UI测试单独抽取出来，可以分为六层）。 单元测试 集成测试 组件测试 契约测试 端到端测试 和测试金字塔的基本原则相同： 越往上，越接近业务/最终用户；越往下，越接近开发 越往上，测试用例越少 越往上，测试成本越高（越耗时，失败时的信息越模糊，越难跟踪） 单元测试 单元测试，即每个微服务内部，对于领域对象，领域逻辑的测试。它的隔离性比较高，无需其他依赖，执行速度较快。 对于业务规则： 商用软件需要License才可以使用，License有时间限制 需要License的软件在到期之前，系统需要发出告警 @Test public void license_should_expire_after_the_evaluation_period() { LocalDate fixed = getDateFrom("2015-09-03"); License license = new License(fixed.toDate(), 1); boolean isExpiredOn = license.isExpiredOn(fixed.plusYears(1).plusDays(1).toDate()); assertTrue(isExpiredOn); } @Test public void license_should_not_expire_before_the_evaluation_period() { LocalDate fixed = getDateFrom("2015-09-05"); License license = new License(fixed....