单测时要不要 mock 数据库?

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

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

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

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

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

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

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

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

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

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


更多文章
  • 动态规划民科教程
  • Golang 分布式异步任务队列 Machinery 教程
  • 使用geohash完成地理距离计算
  • 2018年就要到了,这一年都做了什么呢?
  • 算法导论阅读笔记 --- 排序算法
  • Git HTTPS 如何保存密码
  • 短链系统的实现
  • 程序员修炼之道 阅读笔记
  • Python开发实践经验
  • Golang实现平滑重启(优雅重启)
  • traefik 教程
  • Nginx作为TCP/UDP的负载均衡
  • Web开发系列(十):事务和锁
  • Web开发系列(十一):数据库扩展
  • Web开发系列(九):消息队列,异步任务