cases/<int:pk>/run
运行用例接口
ws/teprunner/cases/<int:case_id>/result/
用例结果查询接口
projects/<int:pk>/export
下载项目环境接口
前端添加WebSocket请求
tep==0.6.9
channels==3.0.3
第一步从请求中获取用例id、运行环境、运行人,这里演示了获取user数据的两种方式:接口传参和从token中解析。然后根据project_id,run_env,user_id定义了pytest项目的路径。
第二步使用tep startproject创建项目文件,清空fixtures和tests目录,目的有两个:一是清掉tep默认fixtures和示例cases,防止对平台产生干扰;二是保证每次运行目录都是干净的,就不用单独去处理前端手动删掉fixture/case后,文件残留的问题。然后从数据库中拉取环境变量、fixtures等数据更新文件。
起多个线程,分别执行用例,执行前先拉取用例代码写入文件,这里是单条用例运行,之所以要用for循环,是因为用例迟早是要批量执行,在设计时就考虑到,避免后面走弯路。然后删掉数据库运行结果,通过subprocess起子进程调用pytest命令,最后在线程的回调函数中根据pytest_result保存用例结果到数据库中。
注意!run_case接口不会直接返回结果,前端是用WebSocket来查询结果的。
if env_name in mapping.keys():
mapping[env_name][name] = value
else:
mapping[env_name] = {name: value}
Content-Type
和Content-Disposition
。红框的代码跟run接口类似,区别在于目录换成了export_temp_dir(),且不包含测试用例,生成zip文件后会把导出临时目录删掉,防止冲突。生产中不建议使用InMemory,可能会有性能问题,而是应该使用Redis: CHANNEL_LAYERS = {
"default": {
"BACKEND": "channels_redis.core.RedisChannelLayer",
"CONFIG": {
"hosts": [("127.0.0.1", 6379)],
},
},
}
第1次,返回用例描述和用例创建人。
第2次,准确说会有多次,当查询数据库没有结果时,会返回计时,前端效果是计时从1s递增。
第3次,如果查询数据库有结果,返回用例结果。
第4次,60s后还没有结果,返回超时信息。
order_by('-run_time')
取的最新一条。最后的self.close()不是必须的,这里加上是因为频繁建立和关闭连接时,如果只是前端发起close(),后端可能会关闭不及时导致channels报错,后端也加上close()能一定程度上避免报错。.env
文件:.env
里面的环境变量。.env
中的环境变量。通过new WebSocket创建socket对象,使用send()发送消息,传了token。onmessage接收后端发过来的消息。如果Server不是用的Django Server而是用的Nginx,需要结合WSGI才能实现多线程。
如果想要多台机器分布式运行用例,就要用pytest-xdist。
参考资料: 前端源码 https://github.com/dongfanger/teprunner-frontend 后端源码 https://github.com/dongfanger/teprunner-backend https://github.com/pytest-dev/pytest-xdist/issues/409 https://blog.csdn.net/weixin_42329277/article/details/80741589 https://www.cnblogs.com/xiao987334176/p/14361893.html https://juejin.cn/post/6844904195758243848 https://segmentfault.com/q/1010000022975655 https://channels.readthedocs.io/en/stable/topics/channel_layers.html https://segmentfault.com/a/1190000018096988 https://www.jianshu.com/p/65807220b44a
联系客服