前言
先抛出结论： 我们也可以用swagger来做契约测试，但过程中需要一些工具的支持。
步骤：
-
首先定义swagger的yaml或者json格式的api specfication，它作为consumer和provider的唯一耦合点，这和Pact中的Json格式契约文件起一样的作用。
-
接着假设provider端还没有开发完成，我们在consumer端做测试，consumer端需要发送request和接收response，这时候就需要第一个工具Prism来支撑，实际上是个mockserver，这个mockserver去解析swagger中的api sepcfication，就可以根据定义的request去返回response。而Prism这个mock server和Pact中consumer端测试中使用的mockserver作用是一样的。
-
最后，假设provider开发出一个版本代码后，需要验证provider端的代码是否能很好的支撑consumer，那它也会先拿到api sepcfication，接着用第二个工具Dredd去在provider端做api specfication的回放，这里和Pact在provider端通过对json格式契约文件的解析后，做request和response的回放是一样的作用。
总结：
整个过程的例子：https://medium.com/@m_arlandy/contract-testing-for-microservices-using-swagger-prism-and-dredd-efdd463b9433
但整个过程中，Pact中的json格式契约文件是在consumer端定义的，所以是consumer driven testing，这是Pact强制要求的。而在Swagger中，这个api specfication可以是服务端定义，也可以时consumer端在做定义，他没有做强制。因此Swagger的契约测试可以做成provider driven,也可以做成consumer driven。
此外，还有一个小的问题，swagger自身带的mock server能在契约测试中发挥作用吗？
swagger自身有一个mock server, 这个mock server的初衷是“后台API还没有开发完成，为了让前台能并行开发”。swagger可以根据定义好的api specfication自动生成一个mock server，然后把这个mock server发给consumer使用。
和前面提到的在客户端提供mock server的工具Prism对比，Prism提供的mock server可以和命令行、CI集成，而Swagger自动生成这个mock server是否能很好的和命令行、CI集成还不清楚。
