mock

一、mock 1、简介 　　mock是一个模拟数据生成器，旨在帮助前端独立于后端进行开发，帮助编写单元测试。其可模拟 Ajax 并返回模拟数据，使前端不用去调用后端的接口，方便测试。 　 2、vue直接使用mock step1：安装mock npm install mockjs step2：直接引入mock.js，并编写mock接口（Mock.mock）。 【mock.js】 //引入mock模块 import Mock from 'mockjs'; Mock.mock('/login', { //输出数据 'name': '@name', //随机生成姓名 //还可以自定义其他数据 }); Mock.mock('/list', { //输出数据 'name': '@name', //随机生成姓名 'age|10-20': 10 //还可以自定义其他数据 }); step3：在需要的地方引入编写后的接口js即可。 【App.vue】 <template> <div> <button @click="login">login</button> <button @click="list">list</button> </div> <!--App --> </template> <script> import mock from './mock.js' import axios from

背景动机 某期优化需要针对通用的HttpClient封装组件--HttpExecutor在保证上层暴露API不动的前提做较多改动，大致包括以下几点： apache http client 版本升级 HttpClientBuilder代码重构 RequestBuilder代码重构 自定义RetryHandler HttpContext扩展 自定义HttpRequestInterceptor/HttpResponseInterceptor 代码很快修改完了，但是如何保证HttpExecutor的行为和以前是一致的呢？很容易就想到是单元测试。因为以前的代码并未提供组件的单元测试，都是依赖QA同学的黑盒测试完成，现有的单元测试又都是在更上层的HttpDao上，重点是对返回数据的解析逻辑代码验证，直接Mock了HttpExecutor的返回结果，完全无法覆盖底层组件的请求逻辑，因此配合本期优化需要提供HttpExecutor组件的单元测试。 需求分析 先大致分析一下HttpExecutor组件提供的功能： 注册apache http client实例的初始化和销毁，包含ConnectionManager等apache http client子功能组件； 上层入参的转封装，以及HttpResponse结果的初步解析封装（response header、status code、response

一、了解 一个在前端本地运行，可以存储json数据的server。在写前端逻辑的时候，可以直接请求交互，添加、更新、删除数据可以直接修改本地json文件里的数据。 二、安装 npm install -g json-server 三、启动 json-server ./mock/data.json mock文件夹下的data.json文件，默认监听3000端口 监听指定端口号 data.json文件 四、浏览器中查看 来源： https://www.cnblogs.com/crackedlove/p/11678076.html

Java使用Mockito 模拟null值 Mockito.isNull(); 来源： https://www.cnblogs.com/bigorang/p/11676286.html

去github上找到eazy-mock下载： https://github.com/easy-mock/easy-mock/tree/v1.6.0 安装eazy-mock所需要的环境： Before starting, we assume that you're already have installed Node.js (>= v8.9) & MongoDB (>= v3.4) & Redis （>= v4.0 ） 由于用的是windows系统 redis使用的是windows系统的v3.2.100 https://github.com/microsoftarchive/redis/releases/tag/win-3.2.100 MongoDB这里用的是v3.4 安装完毕后给easy-mock安装node模块： 进到bin目录，执行npm i 命令 安装完成后配置nodejs配置文件，进入config文件夹，可以看到有个default.config.json文件 打开并编辑 复制官网上的配置复制，只要修改红色部分改为localhost即可 开启mongoDB和redis服务，再进到easy-mock的bin目录执行npm run dev即可开启easy-mock服务，在浏览器打开localhost：7300即可一看到配置界面。 来源： https://www.cnblogs

测试的常用规则 一个测试单元必须关注一个很小的功能函数，证明它是正确的； 每个测试单元必须是完全独立的，必须能单独运行。这样意味着每一个测试方法必须重新加载数据，执行完毕后做一些清理工作。通常通过setUp()和setDown()方法处理； 编写执行快速的测试代码。在某些情况下，测试需要加载复杂的数据结构，而且每次执行的时候都要重新加载，这个时候测试执行会很慢。因此，在这种情况下，可以将这种测试放置一个后台的任务中。 采用测试工具并且学着怎么使用它。 在编写代码前执行完整的测试，而且在编写代码后再重新执行一次。这样能保证你后来编写的代码不会破坏任何事情； 在提交代码前执行完整的测试； 如果在开发期间被打断了工作，写一个打断的单元测试，关于你下一步将要开发的。当你回来工作时，你能知道上一步开发到的指针； 单元测试函数使用长的而且具有描述性的名字。在正式执行代码中，可能使用square()或sqr()取名，但是在测试函数中，你必须取像test_square_of_number_2()、test_square_negativer_number()这些名字，这些名字描述更加清楚； 测试代码必须具有可读性； 单元测试对新进的开发人员来说是工作指南。 二、常见的测试框架 2.1 Unittest unittest是Python内置的标准类库。它的API跟Java的JUnit、

什么是单元测试？如何做好单元测试？ 单元测试是指，对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作，这里的最小可测试单元通常是指函数或者类。 单元测试都是以自动化的方式执行，所以在大量回归测试的场景下更能带来高收益。 单元测试代码里提供函数的使用示例，因为单元测试的具体表现形式就是对函数以各种不同输入参数组合进行调用。 如何做好单元测试？ 1）代码的基本特征与产生错误的原因 无论是开发语言还是脚本语言，都会有条件分支、循环处理和函数调用等最基本的逻辑控制，如果抛开代码需要实现的具体业务逻辑，仅看代码结构的话，所有的代码都是在对数据进行分类处理，每一次条件判定都是一次分类处理，嵌套的条件判定或者循环执行，也是在做分类处理。 如果有任何一个分类遗漏，都会产生缺陷；如果有任何一个分类错误，也会产生缺陷；如果分类正确也没有遗漏，但是分类时的处理逻辑错误，也会产生缺陷。 2）单元测试用例详解 单元测试的用例是一个“输入数据”和“预计输出”的集合。需要针对确定的输入，根据逻辑功能推算出预期正确的输出，并且以执行被测试代码的方式进行验证。即“在明确了代码需要实现的逻辑功能的基础上，什么输入，应该产生什么输出”。 单元测试用例“输入数据”种类： 被测试函数的输入参数； 被测试函数内部需要读取的全局静态变量； 被测试函数内部需要读取的成员变量； 函数内部调用子函数获得的数据

Springboot单元测试Junit深度实践 前言 单元测试的好处估计大家也都知道了，但是大家可以发现在国内IT公司中真正推行单测的很少很少，一些大厂大部分也只是在核心产品推广单测来保障质量，今天这篇文章就是介绍下单测的方法论和如何在Springboot中解决类之间的依赖来实施junit单元测试。 先来他轮下大家不做单元测试的原因： 产品经理天天催进度，哪有时间写UT。 UT是测试自己的代码，自测？那要QA何用？ 自测能测出bug？都是基于自身思维， 就像考试做完第一遍，第二遍检查一样，基本检查不出什么东西 。 UT维护成本太高,投入产出比太低 不会写UT 只有真正尝到UT的好处的甜头才会意识到UT的价值。 其实这篇文章大部分章节是讲述单元测试的难点和解决办法，springboot如何集成其实很简单文章中会讲到。 单元测试的困难 假设我们一个service实现依赖某个RPC Service那我们要测试的这个类的话需要做哪些工作。 第一步：数据准备 跑到别人家的数据库插几条数据？或者跟PRC Service的Owner商量好，搭一个测试环境供我们测试？有些公司还真有专门的自动化测试环境，那么即使有测试环境，那如何实现各种case场景下，第三方Service很配合的返回数据给我们？想想都蛋疼。 第二步：执行方法 假设我们成功的解决了第一步中的问题，皆大欢喜。现在来看第二步

參考： 测试利器之Mock server 介紹 moco server - download 来源： https://www.cnblogs.com/kancy/p/11647950.html

在今天的文章中打算和大家聊一聊关于测试的话题，也许有朋友会问，作为一名码农为什么要关注测试的问题？我们把代码开发完基本自测没问题了，扔给测试不就行了？有问题再改呗！也许有很多人都会这么想，的确，目前国内很多程序员并不太关注Unit Test，很多互联网公司也并没有强制要求开发人员必须编写Unit Test Case。究其原因，可能是国内公司都比较有钱，测试团队动辄几十人，甚至上百人的公司大有人在。所以，从很多程序员的心态上看，测试这么多，直接扔给他们测试就好了！而另外一个被提及的原因，则是国内互联网公司产品迭代速度太快，需求太多做不过来，那里有时间写Unit Test呢？ 也许原因是多样的，但抛开各种各样的因素，今天我们只从程序员成长的角度来聊一聊该不该写Unit Test？最近这段时间和海外的程序员朋友合作开发项目比较多，给我的感受是他们特别强调Unit Test，用他们的话来说比较在意程序的品质。而反观国内很多公司这一点做的就并不是那么好了！之前也和他们聊过其中的原因，他们认为是国内最近这些年的发展太快了，以至于有些过程被跳过了。 我们知道开发一个软件或者平日里在现有的项目中开发某个需求时，严格来说一般会经历这么一个流程，如下图所示： 从图上可以看到，在这个流程中软件被交付集成测试之前，一定要先跑过Unit Test，而现在很多国内公司的测试流程都绕过Unit