业务代码写单元测试的最佳姿势是什么？

[XiLemon]

最近看了极客时间的 [ 10x 程序员工作法] 和 [设计模式专栏] ，里面有一些关于单元测试的内容， 看完之后，感觉好像懂了，但是回头一看自己写出的代码，却不知道如何下手。

想请教一下大家，日常工作中是如何写单元测试的，团队的规范是怎样的，怎么迈出单元测试的第一步！！！

[pkoukk]

@ericgui 你这是集成测试才会出的问题。单测恰好就是规避这种问题的

[no1xsyzy]

1. 需要引数据库就不是单元测试了，已经算集成测试了。
2. 其实单测是 Write Everything Twice 的思想。

话说 you-get 这个项目，提需求是发个 PR，其中包括一个会 fail 的单测

[cxshun]

@XiLemon mock 对象没啥问题，因为一些逻辑有可能是别人写的，你不关注，那就直接 mock 解决，返回你希望返回的数据就好了。至于对方返回有问题，那这是集成测试需要做的东西，单元测试仅关注你自己关注的那块就好了

[lightjiao]

1. 自动化测试确实好用，特别是业务场景越来越复杂的时候，能够指数级的降低测试成本
2. 代码里把一个类所有依赖的第三方对象全都以构造参数的形式传递，方便 mock，比如
```
class Download
{
private Http m_HttpClient;
public Download(Http httpClient)
{
m_HttpClient = httpClient;
}
}
```
3. 每个类自动化生成 mock 类，比如自动生成 HttpMock 、DownloadMock，这样在单元测试时可以方便的吧 mock 对象代替实际的对象传入做测试，这一步主要是单元测试框架完成的，测试时 mock 好每个依赖的 API 的输入输出即可

这种做法可以做到 100%代码行数覆盖的单元测试，实际要完成覆盖多少，根据项目情况来吧

[11ssss]

楼上不点名说了，这些确实是有成本，但是代码质量和接口健壮性甚至对开发者素质是有显著得提升的。但是你自己见识少没见过，不代表没人用没人落地，说话太绝对了。

[timi]

我们推过一段时间单元测试，后来为了单元测试而测试，个人以为核心代码单元测试就得了，CRUD 用接口测试保障就可以了，弄一大坨屎一样的单元测试代码，不好看也不好维护

[ebingtel]

有了测试用例 项目维护起来 得心应手……时间成本随着迭代，越来越低

[www5070504]

真的是方法论 我之前也特别相信这个东西，但是实际上是很难真正去实践的，

如果要实践 TDD 测试代码要来回重构不说，需求文档那边就得写的详细， 但是现在这个行情，你看看有几家能把需求文档写明白的

[crazyhorse]

做 feature test 比较好，刚开始很慢。坚持一段时间你会发现写代码效率高了不少，bug 更少，自己也不用去手动录入数据来做自测

[ChristopherWu]

https://www.v2ex.com/t/776279

请看这个，PBT 测试才是正道

[GoLand]

学习一下这个，面向 interface 编程，这样会发现单元测试很好写。
https://github.com/bxcodec/go-clean-arch

[qwerthhusn]

之前公司突然要求单元测试代码覆盖率，于是我精通了 Java 的 PowerMock，Mockito 的使用，我甚至能把代码行和分支覆盖率提升到接近 100%，但是到了线上还是有 BUG 。、。。

[MonoBiao]

@ccde8259 的确，太头疼了

[sdushn]

看完[ 10x 程序员工作法]会获得[ 10x 薪资不] （手动狗头保命）

[CHANGEX929]

把涉及到其他服务的部分都 mock 掉，数据库、缓存、远程 api 之类的。

[RedisMasterNode]

安利一下腾讯写的 Golang 的单元测试指引
https://mp.weixin.qq.com/s/eAptnygPQcQ5Ex8-6l0byA

[laragh]

@sdushn 并不会 因为我们一个人干多个人的活也不会发多份工资

[XiLemon]

@no1xsyzy 我去了解一下
@cxshun 我感觉可能是现在的方法写的太大了，一个方法做了很多事情，导致许村 mock 多个对象，导致单测很难写
@www5070504 我理解需求文档没写明白的好，最后咋移交的，怎么开发的呢？
@sdushn 不一定会，但能让自己变成一个靠谱的选手
@RedisMasterNode 谢谢，我看一下

[fewok]

1 、你要有技术方案
2 、你要有上下游入口和出口定义
3 、基于入口和出口，搞定依赖、搞定场景数据准备、搞定入口调用
4 、边写业务代码，边写集成测试，或者特变关键的 util，可以专门测试下
5 、基于方法的单测，有一个是一个，我都认为是菜鸟

[qiumaoyuan]

我的理念是不知道做了有什么用的事情就不去做。所有的问题在你对代码质量、开发效率精益求精的过程中自然会遇上，然后再找解决办法。方法是用来解决问题的，没有问题就无所谓方法。很多人研究方法都是在自己没有遇到问题的前提下进行，自然一头雾水。

想想不写测试代码的时候，你是如何人工测试的。为什么有些地方你会进行人工测试，有些地方又很自信很放心的不测试？

代码就是把重复性的事情一次教会给电脑，让电脑去做重复劳动，测试代码也一样。

我觉得结合这两点，基本上就能理出写单元测试的动机和时机。先别管什么 TDD 不 TDD，饭一口一口吃。