尝试为 Service 层的方法添加单元测试,写着写着发现方法中需要用到请求头中携带的 token 获取用户信息才可以走完整套逻辑,那我的单元测试应该要怎样才可以模拟出 token 呢?
1
lanlanye 2022-10-13 19:38:24 +08:00
写一个验证服务的 Stub ,注入你的服务,代替掉真正的验证服务
|
2
retanoj 2022-10-13 19:40:26 +08:00
就各种 mock ,侵入式 mock
|
3
chihiro2014 2022-10-13 19:53:13 +08:00
mock token 对象
|
4
ihuotui 2022-10-13 20:04:50 +08:00
当为类或者方法写单元测试很难写,代表代码耦合度太高,需要解耦,把不同功能的方法分离,才能写出单元测试,从下往上写。如果下面方法都是正确,那么整体代码正确。
|
5
ihuotui 2022-10-13 20:05:21 +08:00
最近写了个单元测试的文章,有点公司内容我修改下发出来。
|
7
hunterzhang86 2022-10-13 20:22:11 +08:00
可以看看 [PowerMock]( https://juejin.cn/post/7152475973412847630),基本上够用了。
|
8
carrymaniac 2022-10-13 20:23:26 +08:00
按照我的理解,service 不太应该和请求头这些东西打交道,解析请求头这些操作在 controller 完成。service 的单元测试也就不用考虑解析 token 等事项了。
|
9
hunterzhang86 2022-10-13 20:23:27 +08:00
|
10
carrymaniac 2022-10-13 20:27:19 +08:00
如果使用的是 springboot mockMVC 的话 可以使用
mockMvc.perform('/xxxx') .with(csrf()) .with(jwt().jwt(jwt))) |
11
hsuyeung OP @carrymaniac 我刚想了下,也是觉得应该这样更好些,使用 mock 局限性太大了(只能去对 controller )做测试
|
12
xavierchow 2022-10-13 20:36:12 +08:00 2
> 刚想了想,我感觉还是应该把“从 token 中获取用户信息”这一操作放到 api 层去处理,然后将用户信息或者其中某些字段作为参数传递到 service 中,service 只处理业务逻辑这样更好些。
对的,这就是写测试代码的好处,促使你重新思考分层 /解耦有么有做好,测试困难很可能代码设计就有坏味道了。 |
13
sdot96 2022-10-14 16:42:35 +08:00
一般都有 mock 包,可以针对变量,方法,接口,函数进行 mock ,如果是 golang 可以看下我的文章有详细的关于单元测试的一些思考 https://zhuanlan.zhihu.com/p/565209330
或者你说的将把“从 token 中获取用户信息”这一操作放到 api 层去处理,我感觉这样好像更加合适,因为我倾向能不 mock 就尽量不 mock |
14
ihuotui 2022-10-14 22:41:19 +08:00
|