单元测试有落地效果好的团队吗？

[tsingke]

团队推单元测试，但是效果很差，开发写单测意愿很低，反馈浪费时间，收益很小，不愿意写。

[varrily]

我们要求覆盖 70%，gitlab ci 强制检测，未通过无法 merge ，包括 codestyle check 。

一开始也不适应，后来也习惯了，一旦覆盖完整，后续逻辑变更会有很大帮助，减少隐患。

跨团队合作还是很有必要的，减少不必要的沟通，避免低级错误。

[Macolor21]

infra 团队, UT 是必须的，还有 IT 、smoke testing ，chaos testing

[dustynight]

我们是 CI 强制要求，不过要求比较低，大概是 line 80%，branch 70%这样，主要是考虑到老代码。

[ichou]

核心项目（ 10 年了）覆盖率 96%，新项目全双百（行覆盖率 100% 分支覆盖率 100%）
加上 commit message 要求比较严格，需求简单交代本次修改的上下文
所以现在写起代码不用担心踩坑儿，即便是祖传代码也是敢动的，没有那种瞻前顾后的心理负担


有了这些基础，加上 QA 的一些自动化测试，我们团队已经践行 ship / show / ask 很久了
比起无穷无尽的 Code Review 和测试回归，效率高了不知多少倍，人力释放出来了，打码人的幸福感还提升了

反正我觉得，真 TM 爽

[ichou]

@dustynight
老代码可以不检查整体覆盖率，直接检查当前 PR 中被变更的行有没有被 100% 覆盖
测试覆盖率慢慢就上去了，也不会因为补测试把人逼疯（大概吧 😂）

[binux]

公司：代码都是屎山，不敢动。
我：没时间写单元测试，能拉出屎就不错了。

论屎山是怎么来的

[SeaTac]

不写 unit test 的组我是不敢去

[akira]

测试代码你给时间了么。。

[petercui]

@y2xworm 重构的时候就知道好了，当然，你们也可能不会重构而是直接重写。

[risky]

单元测试不一定需要项目采用 TDD ，单元测试需要好的程序架构，不然 mock 都不好做，极其痛苦

[heguangyu5]

来分享一下我们最近在做的事,这事要是没有测试保障,很难做成.

我们是做 SASS 招聘管理系统的,开发语言是 PHP,2010 年开始开发,2012 年开始引入 PHPUnit 写单元测试,2020 年做过一次统计,当时代码库有代码约 900 万行. https://zhuanlan.zhihu.com/p/150548910

然后这两年我们想做本地部署,大家知道,PHP 项目做本地部署基本就等于交出了源码.
这是我们不期望的,我们自认为自己产品做的不错,一个几十万元的本地部署项目就把源码给出去太亏了.

那怎么办呢?经过一番调研,我们打算将 PHP 转译成 C,然后编译成二进制,这就好了.
于是就有了我们的 PHP 编译器 BPC. https://github.com/bob-php-compiler/bpc-release
但是 BPC 最终转译出来的 C 代码是否等价于 PHP 呢?
单元测试此时帮了大忙.

1. php 自身及扩展是都有相对完整的测试的,就在 php 源码的 tests 目录里.所以 bpc 如果能够顶替掉 php 解释器,然后还能通过测试的话,那就是最强有力的保障了.然后在 tests 的帮助下,我们实现了 runtime 及需要的扩展. https://github.com/bob-php-compiler/bpc-php-7.2.19-tests
2. 接下来要用 bpc 把 phpunit 编译出来,有了 phpunit,就能确保编译过后的二进制的运行结果和 php 解释器的运行结果一致了. https://github.com/bob-php-compiler/bpc-phpunit.phar-4.8.36
3. 我们的项目是基于 zend framework 1 的,zf1 的单元测试也是用 phpunit 写的,编译 zf1 library,编译 zf1 tests,运行结果一致,zend 就没问题了. https://github.com/bob-php-compiler/zf1
4. 接下来就是我们自己的招聘管理系统了.同样有 phpunit 写的测试保障,只要编译出来运行测试没问题,那就是 99.99%没问题了.

在测试的保障下,现在我们虽然开发的时候用的是 php 解释器,但将来部署出去的话,整个服务器上就几个二进制文件,是没有 php 环境的,测试已经保证了转译后的 C 代码运行结果和 php 一样,这就放心交出去了.

试想如果没有单元测试保障,每一步心里都是忐忑的,还怎么做事呀.

[dog82]

小公司或草台班子根本不写 UT ，因为根本不给写 UT 的时间，即使给了时间，写完单元测试需求都变了 10 次了

大公司产品级的，核心模块肯定要写

[nothingistrue]

迄今为止，就在对日外包当中接触过完整实行的单元测试，不过那是纯人工的单元测试，不是像 Junit 这样的靠测试代码的单元测试。体验上，跟你们开发的反馈差不多，极度消耗时间，且表面上看没收益（对于项目来说是另一码事）。

不管你是调通后再做测试（人工单元测试只能这样），还是编码完成就做测试，单元测试时间跟编码时间的配比，都要至少大于 1:1 。如果不给单元测试分配时间成本，或者在这上面压缩成本，那就不如不做。这个时间成本不一定会提高总成本，因为如果做好单元测试，那么集成测试跟系统测试的成本必然会减小。我参与那个对日外包开发，测试时间基本全部分配到了单元测试上，后面的集成、系统、交付测试的时间非常短。

收益这方面有点复杂，开发过程和考核指标，以及个人的职业发展规划，都会影响对收益的观感。如果你们不管多复杂的开发过程和考核指标，最终都是以项目是否收到尾款作为实际的考核依据，那么单元测试就真得是零收益。如果开发过程上不把编码人跟代码绑定起来，最常见的就是项目结束了就把人派去其他项目，那么单元测试不但是零收益，还是为他人栽树的负收益。如果个人职业规划没有向项目管理、需求或业务方向上发展的话，那么不止单元测试，所有测试对于编码人员来说都是零收益。

最后一方面，单元测试是谁推的也很重要。作为代码质量的一部分，单元测试应当是开发人员自行作为推动动力的。QA 推动也能推起来，不过会遇到阻力的。而假如是开发人员和 QA 之外的人推动，那基本就是全阻力。

[857681664]

我刚加入团队的时候整个项目是没有单元测试的，那时候经常出现改一处问题，又出现好几处其他地方的问题，于是我花了一个月的时间，在项目上搭建了单元测试的框架，并写了第一批测试用例（大约 100 个左右），覆盖了主要业务流程的 6,70%。
对于我来说，单元测试不止有业务迭代，重构时的保障作用，更重要的是，对于修 bug ，测试功能能更快地复现现场。有些功能 /bug 的场景是需要 mq 的，如果在页面上操作需要准备数据，然后经过很多步骤，才能进入待测试方法，而且本地调试很容易误消费消息，带来很多干扰。如果用单元测试，我只需要准备消费者需要的对象，然后在测试方法里调用即可。
我写完第一批测试用例，在团队内推广单元测试的时候，大部分同事也是抱着业务迭代紧，没时间写的想法，也几乎不会去写新的测试，直到后面出现 bug ，我教他们如何复现，如何验证，然后他们也开始觉得测试也挺好用的。
当然我能做完这一切的原因是，我刚加入的时候完全没有需求的压力，只有修复 bug 的任务，所以我才能一边修 bug ，一边验证这一套单元测试的框架。
所以，如果你的团队完全没有意识到测试的重要性，也完全没有给单元测试安排时间，那么建议还是放弃单元测试，让测试人员去做，除非你能说服领导单元测试的好处，能在每次迭代中留有单元测试的时间，那可以在团队中尝试加入单元测试

[Chad0000]

@857681664
我正在架构的微服务全部基于 API ，我感觉这样重现 BUG 会简单些。

[xaplux]

感觉不太容易，目前大部分单元测试并不能覆盖所有测试用例

[abc635073826]

挺好的，最后我们团队被开了，很落地

[binux]

@xaplux 有没有一种可能，写完单元测试之后你还可以写集成测试。

[Huelse]

以前很追求单元测试各种测试，现在除了基础类基本不写，API 测试就行

[exonuclease]

至少需要接口比较稳定的 infra 写起来才比较容易 不稳定的比如 UI 还是用 e2e 测试吧
单元测试的用处不止是 detect bug 可以强制程序员写出容易扩展的代码