关于单测,从测试来看代码编写

最近写了一周多的单测，感触颇多，这里把自己的体会说一下

1. 业务背景现状

在业务开发时，是有单测的，但是单测比较简单，一个业务入口，写了一个单测函数，从头测到尾。

//如 一个给用户数据回放的功能
func  RePlayDataLine(ctx , request){
      .....
}

//对应的单测
func Test_RePlayDataLine(t *testing.T){
}

最基本的业务有两条主流程，回放成功和回放失败，数据回滚。在上线前自测时，先构造“回放成功 ”的数据，运行单测，符合预期。然后 将之前的 测试数据，修成，使之服务构造“回放失败，数据回滚“的条件。 一句话描述，一个单测，测试多个场景，共用一份数据。

2. 问题

当要进行整体测试时，一个 单测只能跑到一个情况，大量的场景测试不到。另外，只有一个入口的整体单测，内部很多函数覆盖不到。

3. 改进

原则上是：一个case ,补充一个单测；一个函数，对应一个单测。

但是做起来远比说起来难。在补单测时发现代码存在许多问题：

3.1 函数参数存在许多的复杂的输入参数

函数参数存在许多的复杂的输入参数；业务运行的时候，从上一个流程到下一个流程，为了传参简单，直接将上层使用的数据接口传入。

例如：

type FuncAData struct{