mvc 架构项目各层如何 mock

最近在用 go 写一个 web 项目,采用 mvc 结构,现在要为该项目mvc 的每一层增加单元测试,这意味着我需要 mock 层间依赖,比如说 UserService 依赖并持有一个 UserRepository 对象,现在为了测试 UserService 的方法,我需要将其内部的 UserRepository 对象替换成 Mock 对象,而这意味着我需要为 UserRepository 创建一个接口 UserRepositoryInterface,然后 UserService 转而依赖该接口,这样我就能在测试时注入 MockUserRepository。

令我感到困惑的是:Go Code Review Comments 中说,不要为了 mock 而专门定义结构,如果像上面那样做,我岂不是违反了这个规则?

但这个规定看起来和我现在遇到的情况相违背呀。像 UserRepository 这样的结构体所拥有的方法只会被 UserService 使用,所以不存在什么根据需要创建接口的情况,我的需要就是为 UserRepository 创建一个大接口。

我想请教的是,对这种 mvc 结构的项目,应该如何 mock?

讨论数量: 9
yourself

最好不要分很多层,数据不一致需要一个个赋值,太酸爽了。

6个月前 评论
zou8944 (楼主) 6个月前
yourself

理想是很好的,我见过更多的是按照合理的分层设计,写出不合理的代码。在复杂的逻辑当中,分层可以合理运用去划分职责,复杂的逻辑要么查询复杂,要么数据组织复杂,或者牵扯一些三方调用,很难说每一层都能发挥出优势,80%情况是只有其中一层特别多的代码,其他层级是摆设。更多时候curd对于划分这么细的层级,这个分层明显非常多余,可能上层只是加了一个方法的调用,但是也要按照每一层都加一个方法,很多人明明分了service层直接在里面写数据查询。分层只是一个思想,划分职责不一定需要分层,可以用组合的方式去处理,我的一个查询可以是一个handle,一个三方调用也可以是一个handle,我可以用一个handle去聚合这些handle去编排,我需要什么handle就聚合什么,组合方式。

6个月前 评论
zou8944 (楼主) 6个月前
yourself (作者) 6个月前

先不论分层的意义,用接口在分层之间解耦合本身也是合理的,实际中也能看到 IDao 这样的设计,不算是为了测试而加。

题主这种需要按不同的情况让 Service 使用不同的 Repository 实现(真的和假的),正是分层和接口的用武之地,说不定哪一天要换另一种实现。

当然,可能永远不会再有另一种实现,这也是很多人嫌弃又臭又长的原因。

1个月前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!