单测时要不要 mock 数据库?

最近我们讨论了一个问题,要不要 mock 数据库? 本文是我的一些个人观点。

首先,对于第三方调用进行 mock ,这是基本都能获得一致意见的,但是是否需要 mock 数据库,则各有分歧。我是赞成不 mock 数据库 的,原因如下:

  • 对于后端业务系统来说,业务代码是围绕着数据库做增删改查从而支撑业务的,换句话说,数据库才是核心,如果 model 层没有得到 测试的覆盖,我认为是不可靠的
  • 不把测试放到数据库跑一遍,可能会遇到一些数据库相关的错误却检查不出来,例如最简单的:SQL拼写错误
  • 对数据库进行 mock 操作需要多写很多mock代码,一般都不会有这么多时间来做这个事情
  • 简单粗暴,方便快捷

那么应该如何测试呢?我一般都是在跑CI的时候,起一个全新的数据库,然后跑数据库 migration,在每一个单元测试 setUp 时 组装数据,在 tearDown 时删除数据。如果是 Go 的单元测试,那么也是类似的,在 Test 函数开始组装数据,defer 删除数据。基本的流程是:

  • 开始单元测试
  • 起一个数据库,用于单元测试
  • 构造单元测试用例所需要的数据,并且插入数据库
  • 执行业务逻辑
  • 检查返回结果以及相关调用是否符合预期
  • 各种断言检查
  • 销毁先前插入的数据,并且删除本次所产生的数据
  • 销毁单元测试所用的数据库

当然,这种模式也有它的弊端:

  • 如果单元测试没有销毁构造的数据以及产生的数据,有可能会对其它测试产生影响
  • 由于需要连接数据库处理,速度上会稍微慢一点

对于第一点,我是真实经历过的,这一点只能靠好好的写测试,清理该清理的数据来做到;第二点,我认为问题不大,也没有那么多 测试代码来跑,数据库能扛住线上的请求,却扛不住单元测试(我知道我知道,配置虽然不太一样)?

而对于 mock 数据库连接这种方式,需要付出很大代价,却无法获得超额的收益,即收益抵不过付出。

这就是我的看法了,你呢?


微信公众号
关注公众号,获得及时更新

更多文章
  • 独立运营博客一年的一些数据分享
  • To B(usiness) 和 To C(ustomer)
  • 常见的软件架构套路
  • Cookie 中的secure和httponly属性
  • Google Ads使用体验
  • Go的custom import path
  • 如何挖掘二级子域名?
  • Go Module 简明教程
  • 写了一个Telegram Bot:自动化分享高质量内容
  • ArchLinux 怎么降级 package ?
  • Vim打开很慢,怎么找出最慢的插件?怎么解决?
  • 为什么我选择放弃运营微信公众号?
  • Web后端工程师进阶指南(2018)
  • How to implement fork syscall in Golang?
  • macOS ansible 遇到 rsync: --chown=www-data: unknown option