请问各位 V2 大佬，一些关于单元测试的问题

还有一个问题是关于被测试代码的颗粒度问题，有大概的规则或者经验用来划分需要测试的代码的颗粒度

要是便于测试的话，那么就把连数据库抽数据的部分和数据处理 /运算的部分分离开，后者独立成一个函数，

这样写单元测试就便于测试它了(单元测试里，可以自己写入测试输入数据 /读配置文件从测试库抽数据测）

可以先考虑下哪些功能要测，哪些功能不用测。
比如说 .find() ，要写单元测试的话，等于是在测 MongoClient 了，没意义。
可以只测 Translate 函数。

当然也可以先插假数据进数据库，然后再测 a()。但是这应该属于集成测试范畴了。

单元测试测逻辑咯。Find 是逻辑吗？不是。不测。
Translate 是逻辑吗？是。那就测。

Translate 中是有多种 condition 或者 translate 方法吗？是。那就拆开测各个逻辑。

关键词：mock

前段时间想通一个事：会到外界产生影响的东西，都该以类似接口、的形式实现
需要添加单元测试时直接 mock 对应实现

这种情况下你可以写一个 helper 来专门在测试开始前创建 seed data，在某个具体的测试函数中先调用这个 helper，然后写你的测试。

测你认为可能出错的地方。如果担心的是数据转换，就把 find 结果 mock 出来单测转换。如果担心的各部分之间的集成，就准备好可控的环境，对整段代码测试。
测试粒度取决于被测的单元，无论这个单元的抽象层级高（比如进行某项业务）还是低（比如格式化一个字符串），测试都应该测目标单元可见的输出。大部分所谓的粒度太细不是测的太细，而是在高层次的测试中描述低层次的细节。比如本意是测试转账业务，但是写出来的代码却在比较格式化后的字符串，必然导致测试难以理解，难以维护。

```
def getDate():
return MongoClient.find();

def a():

outdata = Tranlate(data)


a(getData())


```

总结来说你原来的函数违反了单一职责原则, 在一个函数中干了太多的事情:
它把数据提取和数据转换耦合在一起, 当你需要更换数据源(如测试的使用 mock)就会遇到问题

mock +1

@lihongjie0209 能再请问一下吗？如果我现在有个大的方法，里面每个调用的函数都已经写了，单元测试了，那么如果我想单元测试这个大的函数，是应该 Mock 每个单独调用方法的输出？还是直接运行那个被调用的方法