请教下各位大佬 关于单元测试的问题

[www5070504]

最近遇到几个不知道如何解决或者没有方向的问题 想请教下各位同仁

一是各位平时写代码的时候会写单元测试么, 或者现在写单元测试的人还多么. 现在为了快速上线, 我这里基本没写过单元测试,各位平时是怎么做的呢.

二是在单元测试中不知道各位有没有遇到过无法断言的情况, 比如我一个函数会生成一些二进制数据, 我不知道如何断言这个函数产生的结果是合法的数据. 或者比如一个函数产生一些网络数据包, 但是断言的时候没办法进行比较,因为返回值是不容易预测的.

求各位指教,谢谢各位啦

[remarrexxar]

单元测试覆盖住流程和主要的边界，至少可以保证其他人重构的时候不会失误改坏掉方法，在编译时就可以发现而不是被自动化测试发现再调查。

[orangechengcheng]

单测还是挺重要的，反正我们老大一直在要求单测，还有覆盖率 KPI

[dayeye2006199]

@lzlee 我前东家的代码是 monorepo，整个公司的人都可以随便改代码。而且你的代码依赖一堆上游，和被下游代码依赖。你得保证上游的更改，不会影响到你代码的功能。所以推荐你的代码至少有 80 的单测覆盖。

同时你得保证你改了代码，下游依赖你的代码不会被改动弄挂，所以你也希望别人也写多点测试。一来二去，逼着大家把覆盖率搞上去，否则就是找不自在，找加班。

[namelosw]

> 一是各位平时写代码的时候会写单元测试么, 或者现在写单元测试的人还多么. 现在为了快速上线, 我这里基本没写过单元测试,各位平时是怎么做的呢.

你可以看看 Ruby TDD 有关的教程之类的, 这种情况只有对开发过程, 不怎么损失开发时间的测试才能坚持写. TDD 做得对的情况是可以比较接近这种状态的 — TDD 的核心是驱动开发, 而不是测试.

> 二是在单元测试中不知道各位有没有遇到过无法断言的情况

一个思路是替换或者 Mock, 替换就是依赖注入或者高阶函数, Mock 就是直接 Mock, 除了基础设施之外尽量不要 mock. 就跟随机数一样, 实现里是输入的取真的随机数的实现, 测试里面是可以指定值或者 seed 的实现.

另外一个思路是分离基础设施和模型(业务代码), 然后主要测中间的模型层. 但是小心不要测的粒度太细, 不然你就会发现要不一直在删测试, 要不代码就不能修改.

[asanelder]

关于第二点, 俺同意楼上的.

之所以无法断言, 可能是因为你写代码的时候就不是 TDD 的, 单元测试不是你写完了, 再写测试.

而是通过写测试再写功能, 如果写功能的时候你发现, 不好测试, 无法断言, 可能就是设计有问题

这时要修改设计, 想办法让设计能方便的测试.

这样就是 TDD 的方法论了.

关于第一点, 待过几个公司, 写测试的寥寥无几, 俺也不知道为什么, 反正俺心里不跑一遍, 就心里没底

[asanelder]

还有一点要补充, TDD 是一种方法论, 你要多多实践, 不要过于追求什么如何测, 覆盖率, 什么测哪一层, 粒度等等.

你要知道你测试的目的是什么

1. 改善设计
2. 验证功能没问题

验证功能没问题好说, 那么, 怎么感觉到设计改善了呢?

比如说, 你慢慢感觉,
1. 代码中没那么多硬编码了
2. 每一个组件都可以单独抽出来测有没有问题, 而不是像扯蛋那样, 拿出一个, 要牵连很多
3. 每一个组件是不是可以方便的换掉啊, 比如你有一个本机的环境, 还有一个测试环境, 很可以很方便在在本机运行, 也可以在测试环境运行, 环境相关的东西可以很方便的替换.

总之, 就是能感觉到代码的灵活性.

这就是俺所理解的---<解耦>

[www5070504]

@namelosw
@asanelder

多谢两位 感觉很有帮助 确实我是先写的业务代码才写的单元测试 以后知道怎么做了 感谢

[asanelder]

@www5070504 #48 还有也不是先写测试再写代码, 总之, 俺觉得这不是一个两阶段问题, 也不是一个线性问题, 是一个反复问题, 是一个螺旋上升的问题.

总之, 要记住目的, <写出更好的代码>

不要过于纠结于细节.

[balabalaguguji]

易文档可以写接口的测试用例，可以方便断言 https://easydoc.top

截图：

还有视频教程 https://www.bilibili.com/video/BV1nh411974p?p=8

[liujialongstar]

先写业务再写测试, 写单元测试是因为公司要求覆盖率 80%以上

[why1001]

都不知道 TDD 是啥，我废了

[guyeu]

函数的功能只要可以描述，就可以测。返回值如果无法预期，说明函数实现得有问题。假如返回值无法预期是因为外部依赖（比如 /dev/random ），那么需要把这个外部依赖 mock 掉，只测试属于你这个函数本身的逻辑。

[liuxu]

以前为一个直播项目用 phpunit 写了，全覆盖

[leeg810312]

测试驱动开发（英语缩写 TDD ）以国内的行业习惯应该很难贯彻的。我现在的项目主要都是写 web API，控制器里的代码很少，基本没有单元测试。控制器调用的方法中会选择一些业务逻辑处理占比较高的做单元测试，CRUD 比例高的方法就忽略了，业务逻辑比例高的方法一般都是关键代码，所以需要靠单元测试保障，重构时也容易做回归测试。

[ljf]

垃圾公司，要求覆盖率 80%，否则通报。写的想吐

[slzcz]

正在单元测试的路上.
一开始追求业务快速完成，回头做单元覆盖感觉就是来了一遍重构。

[ZnBDPang]

那当然是，写完自己点来点去

[qoras]

是否写单元测试, 跟很多因素有关, 比如是否有规范明确要求, 是写业务还是写中间件, 给的工期是否充足, 是否有充足的 qa 配比, 接口是否方便通过外部请求来调用.
要是项目时间醒来就紧的很, 还每个都写单测, 那还是自找不痛快

[vindurriel]

测试环节能提供另一种视角来审视你的代码 让边界和接口更合理 更便于参与团队合作 之前不理解依赖注入 控制反转 函数式编程的意义 后来写单测明白了 我一般在写单测的同时重构代码

[OHyn]

前端瑟瑟发抖。
放到 npm 上的包做了自动的 E2E 测试。
封装好的纯 js 工具会写单测。
组件库会写单测---基于 snapshot 的那种。
重要业务流程会写自动 E2E 测试。
明天就上线的什么都不写。