背景：
想借助 Diffy 来实现接口自动化中结果的自动对比。使用过 diffy 的小伙伴可能知道，diffy 的使用需要 3 个服务。primary 和 secondary 这两个稳定的服务版本，以及我们待验证的 candidate 版本。现实中遇到的问题是，我们根本没有那么多的版本供我们使用，这里面有测试资源的问题，跨团队的问题等等。这个时候我们就需要借助 mock 来实现，mock 可以让我们随心所欲的来管理我们的版本数及版本对应的数据。
实现方案：
1、首先我们需要用 mock 来实现三套服务版本的接口，例如分别为：/primary/test/test001、/secondary/test/test001、/candidate/test/test001
如下：
/primary/test/test001：{"test":"001","test001":"primary"}
/secondary/test/test001：{"test":"001","test001":"primary"}
/candidate/test/test001：{"test":"001","test001":"candidate"}
以上，我们就已经完成了三个版本服务的接口 mock。（我这里使用的是 wiremock，大家可以使用自己习惯的 mock 工具）。

2、因为 diffy-server 的配置文件三个服务配置 candidate、master.primary、master.secondary 相同的端口 +IP，因为配置了相同的端口 +IP，所以需要修改下 diffy 的源码，来让代理访问到不同的 mock，这里也给出如下改动的代码。这里这样改是因为我在 mock 接口的时候利用了/candidate/这样的前缀路径来作为环境的区分。

3、接下来就是打包 diffy-server.jar,然后启动的操作，跟常规使用 diffy 是一样的操作步骤啦，这里就不再赘述了。大家可以参考一些网上的教程，比如：http://www.360doc.com/content/22/0618/17/79961355_1036531504.shtml

4、以上是一个 demo 的完成。接下来就是要将这个 demo 融入到你的自动化测试平台或者自动化框架中，大致的思路如下：调试接口直至业务流程都正常，并且返回正常结果，将正常的 2 次请求的结果分别 mock 为 primary 和 secondary，后续接口请求的结果 mock 为 candidate，然后利用 diffy 来进行自动断言。当然要想好用，可能还得对 diffy 做一些二次开发，这一步也是我想接下来完成的。

以上是我这两天的思考和实践，给大家一个参考，也请有经验的小伙伴给的可行性建议或者避坑法则。我也会在后续的完善过程中将遇到的问题和解决方案分享出来。