文章目录
- 单元测试
- 1. 【强制】好的单元测试必须遵守 AIR 原则。
- 1.1 可重复性解析
- 2. 【强制】单元测试应该是全自动执行的,并且非交互式的。
- 3. 【强制】保持单元测试的独立性。
- 4. 【强制】单元测试是可以重复执行的,不能受到外界环境的影响。
- 5. 【强制】对于单元测试,要保证测试粒度足够小,有助于精确定位问题。
- 6. 【强制】核心业务、核心应用、核心模块的增量代码确保单元测试通过。
- 7. 【强制】单元测试代码必须写在如下工程目录: src/test/java,不允许写在业务代码目录下。
- 8. 【推荐】单元测试的基本目标:语句覆盖率达到 70%;核心模块的语句覆盖率和分支覆盖率都要达到 100%
- 9. 【推荐】编写单元测试代码遵守 BCDE 原则,以保证被测试模块的交付质量。
- 10. 【推荐】对于数据库相关的查询,更新,删除等操作,不能假设数据库里的数据是存在的,
- 11.【推荐】和数据库相关的单元测试,可以设定自动回滚机制,不给数据库造成脏数据。或者
- 12.【推荐】对于不可测的代码建议做必要的重构,使代码变得可测
- 13.【推荐】在设计评审阶段,开发人员需要和测试人员一起确定单元测试范围,单元测试最好覆盖所有测试用例。
- 14.【推荐】单元测试作为一种质量保障手段,不建议项目发布后补充单元测试用例,建议在项目提测前完成单元测试。
- 15.【参考】为了更方便地进行单元测试,业务代码应避免以下情况:
- 16.【参考】不要对单元测试存在如下误解:
单元测试
1. 【强制】好的单元测试必须遵守 AIR 原则。
说明: 单元测试在线上运行时,感觉像空气(AIR) 一样并不存在,但在测试质量的保障上,
却是非常关键的。好的单元测试宏观上来说,具有自动化、独立性、可重复执行的特点。
A: Automatic(自动化) 不需要人力来判断正确或者错误
I: Independent(独立性)不可以来别的环境的正常运行来运行单元测试
R: Repeatable(可重复)可以多次重复执行
1.1 可重复性解析
摘自:https://blog.csdn.net/qq_19568599/article/details/54631335
1.1.1Sql的可重复执行的策略
表相关
1.1.1.0一定要加use db_name;
防止运维拿到数据库在错误的库运行,人为错误是一定要避免的
1.1.1.1 新增字段
-- 字段新增
drop PROCEDURE if EXISTS add_column_proc;
CREATE PROCEDURE add_column_proc(t_name varchar(100),col_name varchar(100),datatype varchar(100),remark varchar(255))
BEGIN
DECLARE CurrentDatabase VARCHAR(100);
DECLARE sql_str VARCHAR(1000);
SELECT DATABASE() INTO CurrentDatabase;
if not EXISTS(select 1 FROM information_schema.COLUMNS WHERE TABLE_SCHEMA=CurrentDatabase AND table_name=t_name AND COLUMN_NAME=col_name) then
-- 要执行的字段新增
set @sql_str=concat('ALTER TABLE ',t_name ,' ADD COLUMN ' ,col_name,' ', datatype,' COMMENT \'',remark,'\'');
-- set @sql_str='ALTER TABLE brand ADD COLUMN test varchar(10) DEFAULT NULL NULL COMMENT \'test\'';
-- EXECUTE sql_str;
PREPARE st from @sql_str;
EXECUTE st;
DEALLOCATE PREPARE st;
end if;
END;
-- 支持默认值 约束设置
call add_column_proc('brand','test1','varchar(10)','测试');
call add_column_proc('brand','test1','varchar(10) default null null','测试');
1.1.1.2创建索引
drop PROCEDURE if EXISTS add_index_proc;
CREATE PROCEDURE add_index_proc(t_name varchar(100),_index_name varchar(100),_index_type varchar(100),_index_method varchar(100),col_names varchar(100))
BEGIN
DECLARE CurrentDatabase VARCHAR(100);
DECLARE sql_str VARCHAR(1000);
DECLARE default_index_type VARCHAR(100) DEFAULT 'index';
DECLARE flag int;
SELECT DATABASE() INTO CurrentDatabase;
SELECT 1 FROM information_schema.statistics WHERE table_schema=CurrentDatabase AND table_name = t_name AND index_name = _index_name ;
select CurrentDatabase,t_name,_index_name,flag;
if not EXISTS(SELECT 1 FROM information_schema.statistics WHERE table_schema=CurrentDatabase AND table_name = t_name AND index_name = _index_name ) then
-- 要执行的字段新增
set @default_index_type='index';
set @sql_str=CONCAT('ALTER TABLE ',t_name);
-- set @sql_str=CONCAT(@sql_str,default_index_type);
if _index_type!= '' THEN
set @default_index_type=CONCAT(_index_type,' ',@default_index_type);
end if;
set @sql_str=concat(@sql_str,' add ',@default_index_type,' ',_index_name,'(',col_names,')');
SELECT @sql_str,_index_type,default_index_type,col_names;
-- ALTER TABLE `brand` ADD FULLTEXT INDEX `index_s` (`name`) USING BTREE ;
if _index_method!= '' THEN
set @sql_str=CONCAT(@sql_str,' using ',_index_method);
end if;
PREPARE st from @sql_str;
EXECUTE st;
DEALLOCATE PREPARE st;
end if;
END;
CALL add_index_proc('brand','brand_name','unique','btree','code');
CALL add_index_proc('brand','brand_name','','','code');-- 索引方法、索引名称为空
CALL add_index_proc('brand','brand_name','unique','btree','code,name');-- 组合索引
1.1.1.3插入数据
直接在原insert 语句后面加 ignore关键字,该方式必须表有主键或者唯一索引
use pms_db;
insert ignore into tablename(column) values(column_value)
1.1.1.3新建表
use cims_db;
-- DROP TABLE cims_db.`no_goods_commodity`;
CREATE TABLE if not exists `no_goods_commodity` (
`id` varchar(32) NOT NULL DEFAULT '' COMMENT 'id',
`code` varchar(50) DEFAULT NULL COMMENT '商品编码',
`name` varchar(50) DEFAULT NULL COMMENT '商品名称',
`bar_code` varchar(50) DEFAULT NULL COMMENT '商品条形码',
`buy_type` varchar(50) DEFAULT NULL COMMENT '购买类型',
`category_name` varchar(50) DEFAULT NULL COMMENT '分类名称',
`category_id` varchar(50) DEFAULT NULL COMMENT '分类id',
`vendor_id` varchar(50) DEFAULT NULL COMMENT '供应商id',
`vendor_code` varchar(50) DEFAULT NULL COMMENT '供应商编码',
`vendor_name` varchar(50) DEFAULT NULL COMMENT '供应商名称',
`preferential_price` varchar(50) DEFAULT NULL COMMENT '优惠价',
`stock_limit` varchar(50) DEFAULT NULL COMMENT '0:WMS决定商品可销售数量;1:自定义商品可销售数量',
`area_category` varchar(50) DEFAULT NULL COMMENT ' 是否区域性商品(0:是,1:否).',
`status` varchar(50) DEFAULT NULL COMMENT '商品状态',
`remarks` varchar(50) DEFAULT NULL COMMENT '备注',
`create_by` varchar(50) DEFAULT NULL COMMENT '创建者',
`create_date` timestamp NULL DEFAULT NULL COMMENT '创建日期',
`last_update_by` varchar(50) DEFAULT NULL COMMENT '更新者',
`last_update_date` timestamp NULL DEFAULT NULL COMMENT '更新日期',
`del_flag` varchar(50) DEFAULT NULL COMMENT '删除标记(0:正常;1:删除;2:审核)',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='无货商品汇总表';
1.1.2单元测试的可重复执行
善用数据库的事务
start TRANSACTION;
INSERT INTO `test`.`user` (`username`, `password`, `full_name`, `id`) VALUES ('jack', NULL, 'Jack Jones', '2');
ROLLBACK;
使用rollback,不会新增数据到数据库里
一般等价类可以用Random来产生数据
2. 【强制】单元测试应该是全自动执行的,并且非交互式的。
测试用例通常是被定期执行的,执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元
测试中不准使用 System.out 来进行人肉验证,必须使用 assert 来验证。
为什么?与自动化原则相符合,如果我每次运行脚本都需要人肉看一下,自动化测试就是为了减少认为改错,所以要尽力避免
3. 【强制】保持单元测试的独立性。
为了保证单元测试稳定可靠且便于维护,单元测试用例之间
决不能互相调用,也不能依赖执行的先后次序。
反例: method2 需要依赖 method1 的执行, 将执行结果作为 method2 的输入。
与独立性想符合,这个要求我觉的有点苛刻,登录是必须依赖的,这个没办法。
4. 【强制】单元测试是可以重复执行的,不能受到外界环境的影响。
说明: 单元测试通常会被放到持续集成中,每次有代码 check in 时单元测试都会被执行。如
果单测对外部环境(网络、服务、中间件等) 有依赖,容易导致持续集成机制的不可用。
正例: 为了不受外界环境影响,要求设计代码时就把 SUT 的依赖改成注入,在测试时用 spring
这样的 DI 框架注入一个本地(内存)实现或者 Mock 实现
5. 【强制】对于单元测试,要保证测试粒度足够小,有助于精确定位问题。
单测粒度至多是类级别,一般是方法级别。
说明: 只有测试粒度小才能在出错时尽快定位到出错位置。单测不负责检查跨类或者跨系统的交互逻辑,那是集成测试的领域。
6. 【强制】核心业务、核心应用、核心模块的增量代码确保单元测试通过。
说明: 新增代码及时补充单元测试,如果新增代码影响了原有单元测试,请及时修正。
7. 【强制】单元测试代码必须写在如下工程目录: src/test/java,不允许写在业务代码目录下。
说明: 源码构建时会跳过此目录,而单元测试框架默认是扫描此目录。
8. 【推荐】单元测试的基本目标:语句覆盖率达到 70%;核心模块的语句覆盖率和分支覆盖率都要达到 100%
说明: 在工程规约的应用分层中提到的 DAO 层, Manager 层,可重用度高的 Service,都应该进行单元测试。
9. 【推荐】编写单元测试代码遵守 BCDE 原则,以保证被测试模块的交付质量。
B: Border,边界值测试,包括循环边界、特殊取值等。
循环的边界值,特殊取值,
C: Correct,正确的输入,并得到预期的结果。
D: Design,与设计文档相结合,来编写单元测试。
E: Error,强制错误信息输入(如:非法数据、异常流程、非业务允许输入等),并得
检查
大S小S:特殊时间点0:00
大Sspecial,23:59分
小Ssort 顺序
10. 【推荐】对于数据库相关的查询,更新,删除等操作,不能假设数据库里的数据是存在的,
或者直接操作数据库把数据插入进去,请使用程序插入或者导入数据的方式来准备数据。
反例: 删除某一行数据的单元测试,在数据库中, 先直接手动增加一行作为删除目标,但是这
一行新增数据并不符合业务插入规则, 导致测试结果异常。
要模拟业务数据的插入才算是自动化测试
11.【推荐】和数据库相关的单元测试,可以设定自动回滚机制,不给数据库造成脏数据。或者
对单元测试产生的数据有明确的前后缀标识。
正例: 在 RDC 内部单元测试中,使用 RDC_UNIT_TEST_的前缀标识数据。
12.【推荐】对于不可测的代码建议做必要的重构,使代码变得可测
避免为了达到测试要求而书写不规范测试代码。测试先行是一个很好的习惯
使用python来达到这个目的吧
13.【推荐】在设计评审阶段,开发人员需要和测试人员一起确定单元测试范围,单元测试最好覆盖所有测试用例。
14.【推荐】单元测试作为一种质量保障手段,不建议项目发布后补充单元测试用例,建议在项目提测前完成单元测试。
15.【参考】为了更方便地进行单元测试,业务代码应避免以下情况:
这些都是增加耦合和内聚的事情,
构造方法中做的事情过多。
存在过多的全局变量和静态方法。
存在过多的外部依赖。
存在过多的条件语句。
说明: 多层条件语句建议使用卫语句、策略模式、状态模式等方式重构。
16.【参考】不要对单元测试存在如下误解:
那是测试同学干的事情。本文是开发手册,凡是本文内容都是与开发同学强相关的。
单元测试代码是多余的。 系统的整体功能与各单元部件的测试正常与否是强相关的。
单元测试代码不需要维护。一年半载后,那么单元测试几乎处于废弃状态。
单元测试与线上故障没有辩证关系。好的单元测试能够最大限度地规避线上故障。