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

[tsingke]

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

[y2xworm]

目前经历过的公司除了增加开发难度貌似没啥 bug 能减少的, 特别是改了一些核心功能直接导致一大片单元测试过不了的, 可能代码五分钟改单元测试要改一天😑

[WispZhan]

几个问题，
1. 你在团队属于什么角色，是谁在主导？
2. 采用的什么 TDD 模式，ATDD 、UTDD 或者其他？
3. 团队里平均水平如何？

[chendy]

UT 的作用：1. 发现系统设计的问题 2. 及时变更导致的问题
所以，只对重要且变更比较多的模块写 UT

[Chad0000]

我在引领组里改进架构，也在思考要不要上单元测试。或者 API 测试就行？

同求经验分享。

[superrichman]

单元测试还没写完，需求都改了 10 次。
除非需求没变化，比如一些工具类，一般写好就不会改，不然单元测试收益很低。

[oxromantic]

如果项目周期一半或者一大半的时间不能用来安排测试计划以及写单元测试，那么就不要搞，单元测试需要的时间比实际功能多一些

[lululau]

6L 正解，你一秒钟时间都不给，写个锤子啊；给足了时间谁不喜欢写测试啊，拿着开发的工资写不用动脑子的用例，我就问，谁不喜欢写测试？

[lululau]

测试也是个技术活，也不是完全不用动脑子，用例怎么组织，测试代码怎么复用，测试数据怎么组织管理，外部依赖怎么弄，你个 team leader 都不知道怎么搞，我写个锤子啊

[wu67]

国内这个开发环境, 特别是跟政企有关的项目, 单元测试想都不要想. 上头都拼命催你出界面, 写业务都忙死忙活了, 还整什么测试, 写完丢给测试人员干黑盒就完事了.

[Jooooooooo]

单元测试最大的毛病就是, 随着需求迭代得不停维护. 这个成本某些时候比开发需求还大, 自然没人愿意搞.

[matrix1010]

团队推广单元测试 /集成测试，首先对团队要求就比较高。连看英文文档都费劲的，你让他写测试肯定只会大幅增加他的工作时间。但如果团队水平足够，而且比较拥抱开源，那写测试可能都不用推广，大家都会自觉去做

[yiqiao]

对重构来说确实很有用，特别是复杂业务测试起来有奇效，
但是就是需求变动太快周期太短。

[tediorelee]

进公司的时候才知道有 UT 这个东西，适应了一段时间之后写起来熟练一点了，要求是 branch95, function96.5 ，没达到过不了 Jenkins 的 CI

[ksedz]

在上家公司的时候推过，指标是代码的行覆盖率。
个人感觉实际用起来能发现不少问题，对功能的正确性更有信心了，明显减少了维护时间。
可能对强类型语言的效果有限。

[mikeSbV2]

单元测试？目前的环境想都别想哦。

写单元单测试的时间，起码占开发时间的三分之二。

而且，动不动就更改需求，别想了。

例如：公司上周才上线的需求，下周马上就大改，UI 大改，交互逻辑大改。用户都还未熟悉新功能的交互，立马就改了。还写个 P

[kkkiio]

推行单元测试要以低工作量的方式来推，因为
1. 没人想增加自己的工作量
2. 推行说明之前没写过，开发需要学习如何写单元测试，更要学习如何写出更容易被单元测试的代码
3. 商业考虑性价比，在边边角角浪费时间是不合适的，而且越是边缘的代码一般越不稳定，越容易导致单元测试失效

[neochen13]

别说单元测试,就连接口文档,以及注释你都很难找到全的

[xy90321]

UT 不是 mc/dc 100% 都不会 release 到 IT 环境
不写 UT 只 Coding ？那找 5K 工资的外派就可以了…

[zhaogaz]

不对，问题不对。
1. 要看提出单测的出发点是啥，然后再去针对解决问题，问题不一定用单测解决
2. 单测有很多错误的实践方式，需要有懂的人给你讲，什么场景合适，什么场景不合适。
- 有的是代码设计问题，导致写不出来
- 有的是业务不适合
- 有的是写法不对，导致反复返工，改改改成本过高，废弃
3. 我觉得可能要多想想，问题不一定是表面的问题

[microxiaoxiao]

有点点用吧。我这分子覆盖率要达到 80%。不然都 CI 直接拦截，merge 不了。主要的用途就是确保基本没有问题，而不是靠人的水平来决定。强行提高一下代码的质量。