单元测试

一、异常处理 1、【强制】Java 类库中定义的一类 RuntimeException 可以通过预先检查进行规避，而不应该 通过catch 来处理，比如:IndexOutOfBoundsException，NullPointerException等等。 2、【强制】异常不要用来做流程控制，条件控制，因为异常的处理效率比条件分支低。 3、【强制】对大段代码进行 try-catch，这是不负责任的表现。catch 时请分清稳定代码和非稳 定代码，稳定代码指的是无论如何不会出错的代码。对于非稳定代码的catch尽可能进行区分 异常类型，再做对应的异常处理。 4、【强制】捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之，如果不想处理它，请 将该异常抛给它的调用者。最外层的业务使用者，必须处理异常，将其转化为用户可以理解的 内容。 5、【强制】有 try 块放到了事务代码中，catch 异常后，如果需要回滚事务，一定要注意手动回 滚事务。 6、【强制】finally 块必须对资源对象、流对象进行关闭，有异常也要做 try-catch。 7、【强制】不能在 finally 块中使用 return，finally 块中的 return 返回后方法结束执行，不 会再执行 try 块中的 return 语句。 8、【强制】捕获异常与抛异常，必须是完全匹配，或者捕获异常是抛异常的父类。 ?>

更多技术资讯可关注：gzitcast mock 测试 ock 是辅助单元测试的模块，用于测试不方便调用的别人的接口。举个简单的例子，比如说，我们测试django 写的微信登录接口，正常流程下，我们需要前端拉起授权窗口，获取jscode或其他数据。而这一部分操作，我们在单元测试的时候没办法模拟出来。此时，我们希望假设调用微信的接口，正常返回了我们需要的数据，在这种情况下，我们便需要简单的mock 函数，假设已经该函数正常返回了我们的结果，让流程更通畅。 代码demo： [Python] 纯文本查看 复制代码 ? 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 函数的返回值，指定之后

一 普通测试类 当有一个测试方法的时候，直接运行。 要在方法前后做事情，可以用before或者after。 假如有多个方法运行，则可以选择类进行运行。 1 @RunWith(SpringRunner.class) 2 @SpringBootTest 3 public class TestApplicationTests { 4 ​ 5 ​ 6 @Test 7 public void testOne(){ 8 System.out.println("test hello 1"); 9 TestCase.assertEquals(1, 1); 10 11 } 12 13 @Test 14 public void testTwo(){ 15 System.out.println("test hello 2"); 16 TestCase.assertEquals(1, 1); 17 18 } 19 20 21 22 23 @Before 24 public void testBefore(){ 25 System.out.println("before"); 26 } 27 28 29 30 @After 31 public void testAfter(){ 32 System.out.println("after"); 33 } 34 ​ 35 } 测试结果： 2019-10-28

一、背景 spring项目如需测试小的功能，启动整个项目费时费力，可以使用spring-test包进行单元测试，加速项目开发和测试 二、使用 1.添加maven依赖 <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-test</artifactId> <version>4.3.21.RELEASE</version> </dependency> 2.创建测试类 要测试的是JdbcDaoSupport的功能，因为该类是抽象类，无法实例化，所以需要继承它，由于没有抽象方法，最简实现无需实现任何方法。 package database.dao; import org.springframework.jdbc.core.support.JdbcDaoSupport; /** * JdbcDaoSupport最简实现 * * @author wangying49 * @date 2019/10/28 */ public class SimpleJdbcDao extends

依赖的版本很重要，不要出错了 devDependencies:{ 　　"babel-core": "^6.26.3", 　　"babel-jest": "^22.4.3", "babel-loader": "^7.1.1", "babel-plugin-dynamic-import-webpack": "^1.1.0", "jest": "^24.9.0", "jest-serializer-vue": "^0.3.0", "jest-transform-stub": "^2.0.0", 　 "vue-jest": "^3.0.5", "vue-loader": "^13.7.1", }, moduleFileExtensions: [ 'js', 'jsx', 'json', 'vue' ], globals: { }, transform: { '.*\\.(vue)$': 'vue-jest', '.+\\.(css|styl|less|sass|scss|png|jpg|ttf|woff|woff2)$': 'jest-transform-stub', '^.+\\.js$': '<rootDir>/node_modules/babel-jest' }, transformIgnorePatterns: [ '/node_modules/' ],

Moq框架简单使用 系列目录 Moq库简介及安装 Moq简介 Moq是.net平台下的一个非常流行的模拟库,只要有一个接口它就可以动态生成一个对象,底层使用的是Castle的动态代理功能. 它的流行赖于依赖注入模式的兴起,现在越来越多的分层架构使用依赖注入的方式来解耦层与层之间的关系.最为常见的是数据层和业务逻辑层之间的依赖注入,业务逻辑层不再强依赖数据层对象,而是依赖数据层对象的接口,在IOC容器里完成依赖的配置. 这种解耦给单元测试带来了巨大的便利,使得对业务逻辑的测试可以脱离对数据层的依赖,单元测试的粒度更小,更容易排查出问题所在. 大家可能都知道,数据层的接口往往有很多方法,少则十几个,多则几十个.我们如果在单元测试的时候把接口切换为假实现,即使实现类全是空也需要大量代码,并且这些代码不可重用,一旦接口层改变不但要更改真实数据层实现还要修改这些专为测试做的假实现.这显然是不小的工作量. 幸好有Moq,它可以在编译时动态生成接口的代理对象.大大提高了代码的可维护性,同时也极大减少工作量. 除了动态创建代理外,Moq还可以进行行为测试,触发事件等. Moq安装 Moq安装非常简单,在Nuget里面搜索moq,第一个结果便是moq框架,点击安装即可. Moq简单使用 本示例中要使用到的代码如下 public class MyDto { public string Name {

　现代的专业软件测试中心，随着项目的迭代，通常针对每个系统构建了大量的自动化测试用例集，而启动一次全量的自动化测试以CI级触发，使之大比率通过，非常困难。测试工程师们常常需要投入很高的成本，把大量精力花在自动化用例失败排查上面，然而发现有效BUG的概率很低。在反复排查无果、心神俱疲的情况下，几乎对自动化产生绝望之心，视之为鸡肋，用之无用，弃之可惜，让测试中心极为头疼。 　 　如何让自动化用例发挥它们应有的效用，让QA工作不那么沉重呢？星云测试针对这一难题，进行了精准测试与自动化测试无缝对接的技术方案研发。经过大量企业实施与验证，精准测试的数据流最终可以“无感”对接到自动化测试中，极大扩展了自动化测试的优势，彻底改进了自动化测试变更管理难的短板。 　 　这一技术方案的推出，就像给自动化测试装上“精准测试”的眼睛和翅膀，瞬间就具备了多种飞跃功能。比如： 　1) 自动化测试用例与源码自动建立关联 　2) 同步进行智能回归用例选取 　3) 有效缩小自动化测试执行范围 　4) 即时分析需要进行维护的测试用例集合 　5) 全自动追踪每个测试用例的执行代码路径 　6) 当自动化执行结束后可辅助直接定位自动化用例的代码出错点 　7) 对自动化测试用例集进行分析，例如聚类分析，以及最小用例集合分析等 　8) 对测试用例集的优化给出指导意见 　9) 给出测试用例集运行的总体覆盖率信息 　10)

Webpack4.0中级教程 webpack 作为前端最火的构建工具，是前端自动化工具链 最重要的部分 ，使用门槛较高。本系列是笔者自己的学习记录，比较基础，希望通过 问题 + 解决方式 的模式，以前端构建中遇到的具体需求为出发点，学习 webpack 工具中相应的处理办法。（本篇中的参数配置及使用方式均基于 webpack4.0版本 ） 一. webpack与自动化测试 webpack 对应的关键词是模块化，它的主要任务就是打包和管理模块，所以首先需要明确的概念就是 webpack 之所以关联自动化测试，是因为 它能够为测试脚本提供模块管理的能力 ，本质上来讲，是将 webpack 的打包功能嵌入了自动化测试框架，而不是将自动化测试框架作为插件集成进了 webpack ，理解这个区别是非常关键的。 对于 Karma + Mocha + Chai 及其他自动化测试相关工具的话题将在 《大前端的自动化工厂》 系列博文中讲述，本篇主要介绍 karma-webpack 连接件，它从工具实现层面上将自动化测试与自动化构建联系在了一起。 二. karma-webpack 插件地址： https://github.com/webpack-contrib/karma-webpack 2.1 自动化单元测试库简介 先对基本的单元测试工具做一个简要说明： Karma 测试框架

（一）TestNG介绍与安装 1、介绍 TestNG 官网地址：http://testng.org/doc/ TestNG是一个测试框架的灵感来自JUnit和NUnit,但引入一些新的功能，使它更强大和更容易使用，如： 注释。 在任意大线程池中运行测试，并提供各种策略（所有方法都在自己的线程中，每个测试类有一个线程，等等）。 测试你的代码多线程是安全的。 灵活的测试配置。 数据驱动的测试支持（@dataProvider）。 参数支持。 强大的执行模型(不再有TestSuite)。 通过各种工具和插件支持（Eclipse, IDEA, Maven 等..）。 通过进一步的灵活性Beanshell。 运行时和日志的默认JDK功能(无依赖性)。 应用服务器测试的相关方法。 TestNG 表示下一代(Next Generation的首字母)。它的设计覆盖所有类别的测试：单元、功能、端到端、集成等。 2、安装 本教程基于 IntelliJ IDEA 和 Maven ，所以，这里只介绍 Maven 的安装方式。 <!-- https://mvnrepository.com/artifact/org.testng/testng --> <dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId>

Go语言基础之单元测试 不写测试的开发不是好程序员。我个人非常崇尚TDD（Test Driven Development）的，然而可惜的是国内的程序员都不太关注测试这一部分。 这篇文章主要介绍下在Go语言中如何做单元测试和基准测试。 go test工具 Go语言中的测试依赖 go test 命令。编写测试代码和编写普通的Go代码过程是类似的，并不需要学习新的语法、规则或工具。 go test命令是一个按照一定约定和组织的测试代码的驱动程序。在包目录内，所有以 _test.go 为后缀名的源代码文件都是 go test 测试的一部分，不会被 go build 编译到最终的可执行文件中。 在 *_test.go 文件中有三种类型的函数，单元测试函数、基准测试函数和示例函数。 类型 格式 作用 测试函数 函数名前缀为Test 测试程序的一些逻辑行为是否正确 基准函数 函数名前缀为Benchmark 测试函数的性能 示例函数 函数名前缀为Example 为文档提供示例文档 go test 命令会遍历所有的 *_test.go 文件中符合上述命名规则的函数，然后生成一个临时的main包用于调用相应的测试函数，然后构建并运行、报告测试结果，最后清理测试中生成的临时文件。 测试函数 测试函数的格式 每个测试函数必须导入 testing 包，测试函数的基本格式（签名）如下： func