mock

前言： Mock在GitHub上有12.9K的star可以看出，它在技术团队中是挺受欢迎的。这项技术被应用在不同领域的项目中。 适用场景： 下面我结合我们技术团队，列举最适合引入我们Mock服务的场景： 1、在我们准备开发一个新项目的时候，这时候引入Mock无疑能给我们的开发提速。（排期当然也就可以压一压了，默念：产品看不到，产品看不到） 2、在我们跨部门合作的时候，一些不容易获取的，也就是我们常说的获取难度比较高的接口，需要传很多参数才能获取的。（跨部门合作，经常遇到的，捂脸.gif） 3、一些不稳定的接口，几率性获取失败，经常报异常等（比如：物流接口、省市区接口、包裹实时位置等） 4、比较复杂的测试环境，也称为难创建的环境。 5、测试人员需要提前测接口时，可以先建个Mock，然后再把接口添加到自动化测试环境（建Mock先了解我们接口的数据结构） 6、后端与后端之间如果有接口耦合，也同样也可以适用我们的Mock来解决。（ 是不是眼前一亮 ） 6、前后端分离，前后依赖并行任务（开发自测阶段就可以及早开展，能够提前发现缺陷，我们整个产品质量以及进度得以保证。） Mock的好处是老生常谈了，团队可以并行工作（这个是显而易见的），但是Mock的优势并不是只有这一点。 我们来聊聊 Mock的其他好处 ： 1、测试驱动开发，也就是 TDD模式 。（当接口定义好后

什么是技术视野 网上看到不少关于如何提升技术视野的讨论，但却没有人给出定义，到底什么是技术视野？ 所谓技术视野，就是看问题时所能切换的不同角（维）度。 下面就以API管理工具（以下简称“管理工具”）为例，来探讨背后隐藏的技术视野。 API管理工具 零视角 曾经在一个小型创业公司用到过最简单的管理工具，就是一个开源的文档管理工具，界面功能类似wiki（维基百科）。 这样的工具确实能满足核心需求——API在线文档化，并支持用户管理。 可是深想一层，对于管理工具的使用者——工程师，操作足够友好，功能足够完善吗？ 使用这类管理工具很多时候都会出现文档与代码不一致的情况，也就是说工程师都不愿意去维护这个文档。 因为编写修改文档是个耗费时间的事情，短期来看， 维护了既无利益，不维护也无危害~ 所以有时候接口的变更通过口头协商而非文档协商。 小结：零视角其实谈不上视野，是大多数工程师的最容易形成的思维方式，特点就是只关注功能/问题本身。 单一视角 当时为了解决上面的问题，同时为了练手所学的Node.js，我写了第一版的管理工具，并参加了线下沙龙分享。 现在看来其实当初的写的项目还是比较粗糙的，除了展示界面相较于wiki更加美观之外，主要加入了 Mock 功能。 更好的开源项目也有不少，比如阿里的 RAP 和国外的 APIDOC 。 之所以把它们归为一类讨论，那是因为它们都体现了开发者的单一视角。

以SAP BSP(Business Server Page), ABAP Webdynpro和WebClient UI为代表的SAP UI开发技术，在企业管理软件的前端开发领域里算是独树一帜的存在——因为ABAP提供的OPEN SQL，能够让开发人员直接在任何能编写ABAP代码的地方，直接操作数据库，所以使用这三门开发技术的初学者，很容易在前端编写大量本不应该放在前端实现的代码，最后形成一个前后端高度耦合的应用出来。 这种错误实践的一个例子，比如在WebClient UI的控制器里，直接使用OPEN SQL访问数据库，将数据读取出来后，同样在控制器里，再将这些按照数据库表的格式定义的数据转换成符合UI显示的格式。 比较好的实践，就是把数据库操作封装成一个API，该API返回的结果，通过DTO(Data Transfer Object)转换成可以直接被UI展示的格式，这样UI和控制器都不需要知道底层数据库的格式，实现了前后端的解耦。 今年是Jerry从事自由泳这项运动的第三年了。之前Jerry犯了一个很多自由泳初学者都容易犯的错误：急于以全身配合的方式练习自由泳。采用这种方式练习了一段时间后，Jerry感觉自己的水平停滞不前，于是和堡格莱斯恒温游泳馆的陈教练交流了一下。陈教练说，你还是先练习浮板打腿或者手蹼划水吧。Jerry心想，对啊，这不就是前后端分离吗？

最近我的朋友王小闰进入一家新的公司，正好公司项目采用的是前后端分离架构，技术栈是王小闰非常熟悉的vue全家桶，后端用的是Java语言。 在前后端开发人员碰面之后，协商确定好了前端需要的数据接口（扯那么多，其实也就是关于json数据的字段的定义），然后前后端程序猿就嗨皮地并线开发去了。 前后端联调前夕 我的朋友王小闰他们这家公司做本地旅游项目的，安排到他手上的活儿是该旅游项目的webapp工程。 项目动工伊始，一切都得从头来做。在公司没日没夜的开发了一天之后，王小闰在没有借助vue-cli官方提供的脚手架工具下，徒手从零开始，搭建了一套基于公司特定要求的vue项目的工程架构目录。（关于如何从零开始搭建vue项目的脚手架工程，后面我会单独写一个系列）。 前端项目环境搭建好之后，就正式进入了项目首页的业务编码工作。王小闰又没日没夜的敲了一天代码之后，首页header区域、轮播图以及导航图标的页面布局和逻辑开发都实现了，此时他想调用后端数据测试下流程，但是后端程序猿还没有将该数据的接口开发出来，没办法，我的朋友王小闰此时只能在本地模拟点假数据，逼格高点的说法叫mock数据。 捣鼓半天，首页的mock数据终于弄好了，如下图所示： 但是现在有一个问题让王小闰很困惑，他的axios写的url路径是与后端程序猿商量好的绝对路径（域名 请求路径 请求参数），因为这是以后真正的请求路径

在前后端分离式开发中，经常遇到需要自己 mock 数据测试接口的情况，下面是一种使用 koa2 快速搭建 mock 服务的实现方式。 项目搭建 1. 使用 koa-generator 初始化目录结构 首先全局安装 koa-generator npm install -g koa-generator 在合适位置上初始化目录结构 koa2 mock-server 生成的目录结构如下： 进入该目录并安装依赖 cd mock-server && npm install 2. 运行服务并启用热更新 运行服务 npm run dev dev 指令使用 nodemon 启动服务， nodemon 是 node 的自动重启工具，避免了修改代码后需要手动重启的麻烦。 接下来访问 localhost:3000 就能看到已经启动好的服务了。 koa-generator 生成的路由中默认提供了 index.js 与 users.js 两个路由文件，分别对应了： const router = require ( 'koa-router' ) ( ) // localhost:3000/ router . get ( '/' , async ( ctx , next ) => { await ctx . render ( 'index' , { title : 'Hello Koa 2!' } ) } ) /

安装express: 1 npm install --save express 安装Mockjs: 1 npm install mockjs 建立MockServer.js文件: 1 let express = require('express'); //引入express 2 let Mock = require('mockjs'); //引入mock 3 4 let app = express(); //实例化express 5 6 app.use(function(req, res, next) { 7 res.header("Access-Control-Allow-Origin", "*"); 8 res.header('Access-Control-Allow-Methods', 'PUT, GET, POST, DELETE, OPTIONS'); 9 res.header("Access-Control-Allow-Headers", "X-Requested-With"); 10 res.header('Access-Control-Allow-Headers', 'Content-Type'); 11 next(); 12 }); 13 14 app.use('/api/GetData',function(req, res){ 15 console.log(

关于mock 一、什么是mock？ 通俗来讲，在开发和测试过程中，由于环境不稳定或者协同开发的同事未完成等情况下，有些数据不容易构造或者不容易获取，就创建一个虚拟的对象或者数据样本，用来辅助开发或者测试工作。减轻了对于协同模块的依赖，使开发以及测试变得更加独立。 二、为什么要使用mock？ 现在的很多项目，基本都是划分为一个个小模块进行的，各个模块相互依赖，需要协同进行。但是实际开发过程中，由于各种原因，某些模块在当下可能是不可用的，这就对耦合较高的协同模块会产生不良影响，而使用mock，制造模拟数据，可以减轻这种负面因素。 如下的一些场景，可以使用mock很大程度上减轻这些负面影响。 所需要数据难以获取（比如后端接口没写好，异常、特殊场景的数据）：这些特殊情况和场景下，可能生成一段真实数据很浪费时间，或者当下做不到。而使用mock比真实数据方便很多，此时mock就相当于真实接口数据的替代品，辅助其他相关联模块的开发； 前后端分离，并行开发：前后端商定好接口标准后，按照统一的标准进行同时开发，规避对互相的依赖，减少时间浪费； 前后端分离中，对于某些特殊接口，可能不能实际执行，不然会对数据造成污染，此时可以mock一个返回数据，规避此情况，而又不影响实际开发； 自动化测试：如果在自动化测试中，出现了第三方数据不稳定或者其他情况，会影响测试进度，以及不方便定位问题所在

前端的动态数据交互离不开服务端提供的接口，在一个前后端分离的中后台项目中，接口的请求和响应是必不可少的。 那么在架构一个中后台系统的时候，我们如何有效的管理和封装接口，提高项目接口调用的统一性、可维护性，以及在后端接口还没有开发完成，在仅有契约的基础上我们如何有效的模拟接口的调用呢？ 接下来便会对以上问题提供个人解决方案供大家参考。 1. 不封装存在的问题 首先谈谈接口封装，因为我们使用的请求库是 axios，所以接下来的示例都以 axios 来举例。 那么在没有封装接口的项目中，你可能随处可见接口的直接调用方法，比如像这样： axios.post('/user', { firstName: 'zhang', lastName: 'san' }) .then(function (response) { console.log(response); }); ... axios.get('/user?ID=12345') .then(function (response) { // handle success console.log(response); }); 复制代码 这样的写法会存在一些缺点，主要有以下几点： 接口 url 没有统一管理，散落在项目的各个地方 如果需要在接口调用成功和失败时做一些处理，需要在每个地方进行添加 特殊请求头以及取消请求方法需要单独进行编写 2.

测试存在问题： 1、测试环境接口不稳定 2、业务系统不是孤立存在的，关联方太多，而且关联系统常常出现不稳定的情况 3、暂时无可用Mock server工具 4、接口未提测验收完成，前端测试提前介入 影响： 测试依赖数据，依赖接口阻塞导致测试延期，干耗时间成本人力成本 解决方案： 引入Mock测试，有了Mock，测试童鞋在后端接口未准备好时按照接口文档就可以开始造数据进行测试工作，不会出现测试一直等待开发的情况，也可以开发联调与测试进行。这样的话，开发自测阶段就可以及早开展，从而发现缺陷的时机也提前了，有利于整个产品app测试覆盖率提升和产品项目进度的保证 2、环境配置及准备 2.1、安装charles及一些配置项说明 去 Charles 的官方网站（ http://www.charlesproxy.com ）下载最新版的 Charles 安装包，是一个 dmg 后缀的文件。打开后将 Charles 拖到 Application 目录下即完成安装。 2.1.1将 Charles 设置成系统代理 Charles 是通过将自己设置成代理服务器来完成封包截取的，所以使用 Charles 的第一步是将其设置成系统的代理服务器。 启动 Charles 后，第一次 Charles 会请求你给它设置系统代理的权限。你可以输入登录密码授予 Charles 该权限。你也可以忽略该请求，然后在需要将

mock中测试private方法,不是mock : Method method = PowerMockito.method(CategoryController.class, "getCategory",List.class);//创建调用CategoryController类中的getCategory私有方法的method对象,参数是list对象 List<Category> category_all_actual = (List<Category>)method.invoke(categoryController, categories);//调用categoryController的私有方法,返回list对象,参数是list对象 assertArrayEquals(category_all_expect.toArray(), category_all_actual.toArray());//比较实际返回的对象与期望的对象是否相等. 或者:// PowerMockito.doReturn(index_expect).when(controller, "processPage", pageCode, request, response, model); // Mock私有方法 或者: // PowerMockito.when(controller, "processPage",