Gene Mock Server今天我们是在工程化的主题里分享一个Mock工具，看完简介你也许会觉得这是就是一个Mock

今天我们是在工程化的主题里分享一个Mock工具，看完简介你也许会觉得这是就是一个Mock平台。首先本质上，是的！那么它有什么特别呢？

痛点

我想在使用mock的过程中我们都会遇到各种各样的痛点，我总结了如下2个方面。

工程使用方面：

首先，目前大部分的项目都需要单独对接mock方案，我们需要自己去看对接 mock平台的文档、使用方式等等，没有统一的一个方式或者简单的方式。甚至在团队整体切换mock平台时又要重来一遍。其次，工程对接的mock数据一般比较简单，数据只有一份，没有场景区分，并且很容易被其他人误改。例如：开发A测试功能将mock数据修改后，开发B之前mock的数据很可能已经被删除，下次再验证问题又会需要时间去模拟数据，影响了我们的开发效率。

再者，我们目前修改本地mock数据一般都是直接代码里搜索修改，如下图，缺少界面化的操作。

那么你肯定会说已经有比较成熟的mock平台了，为什么不使用呢？那么我们来对比一下。

演示

那么下面我来为大家简单介绍Gene Mock Server的基本功能。

我们先描述一个应用场景：系统有角色权限控制，同时某个详情页的操作也有状态控制。

接口列表

新增接口

可自动输入，也可根据列表选择，列表数据可来源于其他平台，例如我们的dip接口定义平台。

创建接口场景

不同的用户角色会返回不同的权限数据，可以利用场景做区分控制

设置接口默认场景

同一时刻同一接口只能开启一个默认场景

场景中心

场景中心是可以利用用户定义的接口场景自定义组合成一个场景组，可以批量的操作场景的开启关闭，提高了场景切换的效率和简易度。

新增路由

采用路由维度一方面是因为一般开发一个页面就代表一个完整的功能模块，另一方面也方便场景组的查找分类。

新增路由场景组

编辑场景组的接口及场景

注意：同一时刻，同一页面只能有一个场景组开启，多页面多场景可以同时开启。且场景组开启状态下的接口场景优先级高于接口列表的场景开启状态。

特性

我给它的定位是gene工程化中的一个功能模块，提供场景组mock的功能，同时支持扩展。它有3方面的特性。

集成方便

针对我们上文中说到的工程使用方面的第一个痛点，我们提供了统一的使用方式。

使用我们预设的工程化模版引入，里面自带mock功能。

第一步：安装npm包

tnpm i @kaola/gene.cli @kaola/gene.presets-basic -D

第二步：修改package.json

"scripts": {
    "mock": "gene mock",
 },
 "gene": {
    "presets": "@kaola/gene.presets-basic"
 },
"devDependencies": {
    "@kaola/gene.cli": "^0.1.0",
    "@kaola/gene.presets-basic": "0.0.4"
}

第三步：配置mock.config.js

module.exports = function () {
  return {
    config: {}, // 配置
    plugins: {}, // 插件
  }
}

第四步：配置代理

// pages.config.js 修改代理
module.exports = function ( { command } = {} ) {
  return {
    config: {
      webpack: {
        devServer: {
          proxy: {
            '/api': 'http://127.0.0.1:8001',
          }
        }
      }
    }
  }
}

如果你不想整体引入工程化方案，只想利用我们的mock功能，可单独使用mock部分，然后将您的服务代理到mock上即可。

第五步：启动、访问

// 启动
npm run mock
// 访问
http://localhost:8001

支持场景组一键切换

针对功能复杂，涉及接口多的大型复杂场景，可以利用我们提供的场景组的功能一键场景切换，完成各种测试验收。以下是我们真实项目中的一个页面应用。假设有一个需求，在售后单区域增加【已发货待验货异常数据】。

想必所有人看到以上需求都会觉得几分钟能搞定的事情。但是修改代码，页面验证大部分开发角色会看到如下效果

所以我们需要花费时间去看代码逻辑，怎样将售后单模块展示出来。分析代码发现需要特定角色、展示项动态配置、数据不为0 三种条件同时满足才会展示。所以我们修改各种配置和数据让其展示然后验证，这个过程会花费至少十几分钟时间，对于不熟悉此工程的开发，耗时更多。

而使用场景组合需要怎么操作呢？

第一步：开启对应场景组

第二步：修改代码

第三步：页面验收确认

扩展性

这个特性跟我们的实现设计有关，基本的结构如下图：

driver-mock（mock server）只提供核心功能，例如接口新增、场景及场景组编辑、mock数据修改的功能。其他的能力我们利用gene的插件体系开放一些api供其他自定义的插件调用。例如：我们前端组辰俊开发了对接dip的插件@kaola/plugin-dip-mock，可以自动将dip的数据、接口定义对接到mock平台上，避免了我们创建接口和mock数据时手动输入的时间耗费。

核心实现只提供基本功能的考虑是因为外层对接可能是多变的，就好像考拉的接口定义平台从nei到dip，但是对于业务开发者来说，我们是希望可以不感知到这种变化的。为了保证用户体验一致，我们只需要在对接平台切换的时候修改产出对应的插件，但mock平台用户使用方式仍和之前一致，无额外学习对接成本。

下面是我们提供的一些钩子，如果有兴趣开发扩展其他能力的，欢迎随时来联系我 @莫力

fetchSchemas：获取自动填充的API，避免手动输入API

featchSchemasScenes：获取其他平台API已有的相应场景

fetchSceneMockData：根据场景获取API数据，优先本地再远程

notFound：当本地mock不存在时代理请求远程数据

规划

后续我们想借助基础的场景组功能来对接UI测试、走通视觉验收等流程。

PS:有兴趣可以查看方凳会114期分享

Gene Mock Server

痛点