单元测试

1: 测试分类 2: 常用测试方法 2.1 断言语句 3: 基本测试 4: 组合测试 5: 参数化测试 6: 分类测试 (Category) 1:测试分类 1. 黑盒测试：不需要写代码，给输入值，看程序是否能够输出期望的值。 2. 白盒测试：需要写代码的。关注程序具体的执行流程。 2:常用测试方法 Junit 组合测试注解 : RunWith 指定测试类的为指定容器 可以为 Category SuitCase Parametered 建立参数类 且必须提供一个内部的静态方法 返回一个集合的 Collection<Object[]> Runwith 必须是 Parameterized.class Category 将测试方法 分类 RunWith 必须指定为 Categories.class FixMethodOrder 定义测试次序 2.1 断言语句 Assert 类 以静态方法 提供了一系列的测试方法 Method Description assertNull(java.lang.Object object) 检查对象是否为空 assertNotNull(java.lang.Object object) 检查对象是否不为空 assertEquals(long expected, long actual) 检查 long 类型的值是否相等 assertEquals(double

-DskipTests，不执行测试用例，但编译测试用例类生成相应的class文件至target/test-classes下。 -Dmaven.test.skip=true，不执行测试用例，也不编译测试用例类。 不执行测试用例，但编译测试用例类生成相应的class文件至target/test-classes下。 一 使用maven.test.skip，不但跳过单元测试的运行，也跳过测试代码的编译。 [html] view plain copy -Dmaven.test.skip = true 也可以在pom.xml文件中修改 [html] view plain copy < plugin > < groupId > org.apache.maven.plugin </ groupId > < artifactId > maven-compiler-plugin </ artifactId > < version > 2.1 </ version > < configuration > < skip > true </ skip > </ configuration > </ plugin > < plugin > < groupId > org.apache.maven.plugins </ groupId > < artifactId > maven-surefire-plugin

Google Mock 入门概述什么是Mock? Mock，更确切地说应该是Mock Object。它究竟是什么？它有什么作用？在这里，我也只能先说说我的理解。 比如当我们在单元测试、模块的接口测试时，当这个模块需要依赖另外一个/几个类，而这时这些个类还没有开发好（那名开发同学比较懒，呵呵），这时我们就可以定义了Mock对象来模拟那些类的行为。 说得更直白一些，就是自己实现一个假的依赖类，对这个类的方法你想要什么行为就可以有什么行为，你想让这个方法返回什么结果就可以返回怎么样的结果。 但这时很多同学往往会提出一个问题："那既然是我自己实现一个假的依赖类"，那和那些市面上的Mock框架有什么关系啊？ 这个其实是这样的，这些个Mock框架可以帮助你比较方便、比较轻松地实现这些个假的依赖类。毕竟，如果你实现这么一个假的依赖类的时间花费过场的话，那我还不如等待那位懒惰的同学吧。 Google Mock概述 Google Mock （简称 gmock ）是Google在2008年推出的一套针对C++的Mock框架，它灵感取自于 jMock 、 EasyMock 、 harcreat 。它提供了以下这些特性： 轻松地创建mock类 支持丰富的匹配器（Matcher）和行为（Action） 支持有序、无序、部分有序的期望行为的定义 多平台的支持 参考文档 新人手册 Cheat Sheet

从网上找了很多例子关于单元测试，都是如何新建项目的时候的添加单元测试，用vue-cli中怎么添加，但是我的项目已经生成了，不能再一次重新初始化，这时如何添加单元测试，这里面遇到了好多坑，写在这里记录一下心得。 vue init webpack vuetest npm i -D karma karma -webpack phantomjs -prebuilt karma -phantomjs -launcher karma -phantomjs -shim karma -chrome -launcher karma -sourcemap -loader mocha karma -mocha sinon chai sinon -chai karma -sinon -chai karma -spec -reporter karma -coverage istanbul -instrumenter -loader "unit" : "karma start test/unit/karma.conf.js --single-run" , const srcContext = require .context( '../../src' , true , /^\.\/(?!main(\.js)?$)/ ) 改为： const srcContext = require .context( '../

在运行测试的时候抛异常了： “System.InvalidOperationException”类型的异常在 mscorlib.dll 中发生，但未在用户代码中进行处理 The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. 经过一些列的百度最后，看到这篇博客 https://blog.csdn.net/haipurui0001/article/details/79355160 的一句话

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

单元测试简介：https://segmentfault.com/a/1190000009737186 单元测试-Jasmine：https://segmentfault.com/a/1190000009737204 angular2单元测试：https://segmentfault.com/a/1190000009769787#articleHeader1 概念简介 Jasmine Jasmine测试框架提供了编写测试脚本的工具集，而且非常优秀的语义化，让测试代码看起来像是在读一段话。 describe，beforeEach，it，expect等方法，利用这些方法可以定义单元测试如何执行，单元测试的结果和预期。 官方文档：https://jasmine.github.io/api/edge/global.html#expect Karma 有Jasmine测试脚本，还需要Karma来帮忙管理这些脚本，以便于在浏览器中运行，可以理解Karma为运行这些测试脚本的容器。 需要在根目录创建 karma.conf.js 文件，这相当于一些约定。文件是为了告知karma需要启用哪些插件、加载哪些测试脚本、需要哪些测试浏览器环境、测试报告通知方式、日志等等。 官方文档：https://karma-runner.github.io/1.0/config/configuration-file

前言 最近有幸跟随资深ThoughtWorks咨询师熊节老师一起学习测试驱动设计，经过短暂的十几天培训，对测试驱动设计的基本原则、实践模式、技巧有了一点点初步的认识。 在此之前，经常自嘲我经历的公司实践也似乎是TDD， 这种实践往往都是由测试工程师来驱动开发者完成bug的修改，虽然也是测试来驱动开发，但是却与真正的TDD大相径庭。 什么是TDD 在维基百科中是这样对TDD下定义的： 测试驱动开发（英语：Test-driven development，缩写为TDD）是一种软件开发过程中的应用方法，由极限编程中倡导，以其倡导先写测试程序，然后编码实现其功能得名。测试驱动开发始于20世纪90年代。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。 测试驱动开发是戴两顶帽子思考的开发方式：先戴上实现功能的帽子，在测试的辅助下，快速实现其功能；再戴上重构的帽子，在测试的保护下，通过去除冗余的代码，提高代码质量。测试驱动着整个开发过程：首先，驱动代码的设计和功能的实现；其后，驱动代码的再设计和重构。 测试驱动开发也是国外许多优秀开发者向开发者们推荐的一种普遍适用的开发模式，而在熊节老师的培训课程中，他时刻在向开发者灌输来自TDD的三条原则，要求我们的编写生产代码前，一定应该先编写单元测试。 定律一：在编写不能通过的单元测试前

git地址 github链接 git用户名 namehousiqi 学号后五位 62124 博客地址 个人博客 作业链接 作业 阿超家里的孩子上小学一年级了，这个暑假老师给家长们布置了一个作业：家长每天要给孩子出一些合理的，但要有些难度的四则运算题目，并且家长要对孩子的作业打分记录。 作为程序员的阿超心想，既然每天都需要出题，那何不做一个可以自动生成小学四则运算题目与解决题目的命令行 “软件”呢。他把老师的话翻译一下，就形成了这个软件的需求： 程序接收一个命令行参数 n，然后随机产生 n 道加减乘除（分别使用符号+-*/来表示）练习题，每个数字在 0 和 100 之间，运算符在 2 个 到 3 个之间。 由于阿超的孩子才上一年级，并不知道分数。所以软件所出的练习题在运算过程中不得出现非整数，比如不能出现 3÷5+2=2.6 这样的算式。 练习题生成好后，将生成的 n 道练习题及其对应的正确答案输出到一个文件 subject.txt 中。 当程序接收的参数为4时，以下为一个输出文件示例。 13+17-1=29 11*15-5=160 3+10+4-16=1 15÷5+3-2=4 由于之前提前安装有visio studio 2013版的，因此为了节省安装软件的时间这里就直接使用该版本的编译器来编写该程序。 先fork了老师要求的在gethub上的题。

mock 测试 ock 是辅助单元测试的模块，用于测试不方便调用的别人的接口。举个简单的例子，比如说，我们测试django 写的微信登录接口，正常流程下，我们需要前端拉起授权窗口，获取jscode或其他数据。而这一部分操作，我们在单元测试的时候没办法模拟出来。此时，我们希望假设调用微信的接口，正常返回了我们需要的数据，在这种情况下，我们便需要简单的mock 函数，假设已经该函数正常返回了我们的结果，让流程更通畅。 代码demo： 复制代码 ? 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 from rest_framework.test import APITestCase from unittest import mock class AdviserTest(APITestCase): # mock.patch 中指定我们需要mock的函数路径（使用时的路径） @mock .patch( "adviser.views.jscode2session" ) def test_small_app_login( self , mock_jscode2session): # 添加mock 函数的返回值，指定之后，所有的调用到该函数的地方，统一返回 mock_jscode2session.return