测试平台系列(84)|测试平台系列(84) 支持复制其他前置条件
大家好~我是回顾米洛
!
我正在从0到1打造一个开源的接口测试平台, 也在编写一套与之对应的完整教程
,希望大家多多支持。
欢迎关注我的公众号测试开发坑货
,获取最新文章教程!
前文我们支持了Redis这种
前置条件
,但其实有个特别不友好的地方:如果前置条件比较接近,我甚至于不能复制它们。
如果能像前置case一样,选择一个去快速
复制
,所以说这样是十分不友好的。那这一节我们就来实现它。
效果图
老规矩,先放上效果图:
文章图片
思路
其实要支持这个操作,对于后端来说还是比较简单的。
好在我们的后端的Constructor有个type字段,用于区分前置条件的类型。所以我们只需要安排一个
查询接口
:根据类型查找出前置条件的明细,然后选择后,前端用表单的方式带入进来,即可复制整个前置条件。
后端先行
编写查询接口,展示它属于哪一个case,并且给出前置条件的细节。
前端呢,则是已经确定好了TreeSelect组件,所以后端采用2层的数据格式:
[
{
"title": "用例",
"key": "caseid",
"children": [
{
"title": "数据构造器A",
"key":
"constructor_id"
}
]}
]
那我们就
造起来
吧~- 编写思路
我不打算用join(从一开始我就贯彻了自己这个思想,我更喜欢用2次查询,自己拼接数据的方式,其实是join用的不好)
我们优先查出对应类型的前置条件
,接着就能拿到所有case_id了,再用case_id去查出case的信息,岂不美哉?
只是难点在于怎么组成这个树,但其实这个树只有2层,我们要做的就是先组装children,最后拼parent。
这里我们就要用到defaultdict
了。
- 查出符合条件的前置条件,并根据case_id为key,前置条件为value的方式,存放到defaultdict
- 根据defaultdict的keys查出case_id对应的case名称,遍历之,拼凑parent,并把defaultdict里面的value放到children字段。
@staticmethod
async def get_case_and_constructor(constructor_type: int):
# 最终返回结果树
ans = list()
async with async_session() as session:
# 此处存放case_id => 前置条件的映射
constructors = defaultdict(list)
# 根据传入的前置条件类型,找出所有前置条件, 类型一致,共享开关打开,并未被删除
query = await session.execute(
select(Constructor).where(
Constructor.type == constructor_type,
Constructor.public == True,
Constructor.deleted_at == None))
# 并把这些前置条件放到constructors里面
for q in query.scalars().all():
constructors[q.case_id].append({
"title": q.name,
"key": f"{q.id}",
"isLeaf": True,
# 这里是为了拿到具体的代码,因为树一般只有name和id,我们这还需要其他数据
"constructor_json": q.constructor_json,
})# 二次查询,查出有前置条件的case
query = await session.execute(
select(TestCase).where(TestCase.id.in_(constructors.keys()), TestCase.deleted_at == None))
# 构造树,要知道children已经构建好了,就在constructors里面
for q in query.scalars().all():
# 把用例id放入cs_list,这里就不用原生join了
ans.append({
"title": q.name,
"key": f"case_{q.id}",
"disabled": True,
"children": constructors[q.id]
})
return ans
注释写的非常详细,每一步都交代的
很清楚
。接着是接口部分,就不需要多说了:
# 获取所有数据构造器
@router.get("/constructor/list")
async def list_case_and_constructor(constructor_type: int):
try:
ans = await ConstructorDao.get_case_and_constructor(constructor_type)
return PityResponse.success(ans)
except Exception as e:
return PityResponse.failed(str(e))
前端适配
其实前端适配很简单,加一个组件,并且在组件选中值的时候更新表单的值就可以了。
oh shit~~
写到这里我才发现我居然写过类似的代码,难受= =
文章图片
果然人会在同一个地方倒下,不过我觉得之前写的,没有对前置条件进行分类,所以我得改造改造,或者说这次写的当做v2接口使用。
不得不说,前端的改动比想象中还
大一点
。仔细比对了这个接口,发现它的逻辑是:- 找到对应的前置条件id
- 查询前置条件的数据,进行替换
我们目前把它做了一个船新版本来适配我们所有的类型:
import {Col, Row, TreeSelect} from "antd";
import {connect} from 'umi';
import {useEffect} from "react";
const CopyTreeSelect = ({construct, dispatch}) => {const {constructorData, searchConstructor, constructorType} = construct;
const save = (data) => {
dispatch({
type: 'construct/save',
payload: data,
})
}const getConstructorData = https://www.it610.com/article/() => {
dispatch({
type: 'construct/getConstructorTree',
payload: {
constructor_type: constructorType
}
})
}useEffect(() => {
getConstructorData();
}, [constructorType])return (
{
return treeNode.title.toLowerCase().indexOf(inputValue.toLowerCase()) > -1
}}
dropdownStyle={{maxHeight: 600, overflow: 'auto'}}
treeData=https://www.it610.com/article/{constructorData}
placeholder="通过搜索构造条件,可以快速复制参数哦!"
treeDefaultExpandAll
onChange={(e) => {
save({searchConstructor: e})
if (e !== undefined) {
dispatch({
type: 'construct/getConstructorData',
payload: {id: e.split("_")[1]}
})
} else {
dispatch({
type: 'construct/save',
payload: {testCaseConstructorData: {type: constructorType, public: true, enable: true}},
})
}
}}
/>
)
}export default connect(({loading, construct}) => ({loading, construct}))(CopyTreeSelect);
把这个组件单独抽出,成为一个
copy组件
。并在前置条件类型变化的时候,自动更换数据源
。页面上再进行一些微调,就ok了。说实话这块有点臃肿,由于我自己都看不下去,所以我先放过自己,也放过大家。
【测试平台系列(84)|测试平台系列(84) 支持复制其他前置条件】下一节我们小试牛刀,编写一个简单的
测试报告邮件通知
功能。(其实说简单也不简单,如果要设计到样式,还挺麻烦
)推荐阅读
- 基于微信小程序带后端ssm接口小区物业管理平台设计
- 【欢喜是你·三宅系列①】⑶
- 你不可不知的真相系列之科学
- 人脸识别|【人脸识别系列】| 实现自动化妆
- 女生该不该用小号测试男朋友()
- BNC公链|BNC公链 | Eth2.0测试网Topaz已质押超100万枚ETH
- 2018-06-13金句系列7(金句结构-改编古现代诗词)
- Unity和Android通信系列文章2——扩展UnityPlayerActivity
- 乡野村趣系列之烧仙草
- Java内存泄漏分析系列之二(jstack生成的Thread|Java内存泄漏分析系列之二:jstack生成的Thread Dump日志结构解析)