0x01 TDD的局限
单元测试，面向单体应用。优缺点不细讲，可自行搜索。在微服务架构中，我们如果使用单元测试代价太大，而且微服务之间经常会有耦合的情况，在测试A服务的时候不可避免的要启动依赖的其他服务，这样成本会很高，而且debug困难，测试效率低。如果我们对A服务的依赖服务实现stub，这样测试效率可以大大提高。 还有一种情况是A服务的Provider服务的接口发生改变，我们需要立刻捕捉这个改变，从而修改对这个API依赖的服务调用。
0x02 CDC
契约测试，又称之为 消费者驱动的契约测试(Consumer-Driven Contracts，简称CDC)，根据消费者驱动契约，我们可以将服务分为消费者端和生产者端，而消费者驱动的契约测试的核心思想在于是从消费者业务实现的角度出发，由消费者自己会定义需要的数据格式以及交互细节，并驱动生成一份契约文件。然后生产者根据契约文件来实现自己的逻辑，并在持续集成环境中持续验证。
- cdc是以消费者提出接口契约，交由服务提供方实现，并以测试用例对契约进行产生约束，所以服务提供方在满足测试用例的情况下可以自行更改接口或架构实现而不影响消费者。
- cdc是一种针对外部服务的接口进行的测试，它能够验证服务是否满足消费方期待的契约。 它的本质是从利益相关者的目标和动机出发，最大限度地满足需求方的业务价值实现。
0x03 Spring Cloud Contract
Spring Cloud Contract算是CDC一个比较好的实践，在接入这个框架的过程中，小坑还是不可避免的踩了一些。
- 入门教程参见官网提供的sample，这个能解决大多数的问题。
- 在我对CDC的应用仅对REST的API做测试，message目前先忽略。
- 由于对groovy掌握不熟，所以用yaml做契约定义。
- 对http的集成在于定义了契约后，SCC将契约文件转成wiremock可以识别的json文件，然后打成stub，在使用的时候就可以在本地使用WireMock来mock一个http service。
- 在yaml中url无法使用正则来匹配RequestParam/PathVariables，可自行使用WireMock实现。
- 在对微服务的CDC中，我们可以在
src/test/resources/application.yml中加入下面配置来实现stubrunner: idsToServiceIds: kof-logic-server: kof-switcher-1 # stub jar: microservice name