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

我不知道怎么写单元测试。比如一个仓库入库出库和物流的业务，这个要怎么写

业务稳定了才开始写单元测试，不稳定的时候写单元测试是找死。

觉得写测试浪费时间，收益小，有几种可能。
1. 项目活不了那么久，要么天天改，要么月月倒闭，一个系统写完了，用不了几天就扔了。
2. 资历太浅，没有经历过技术债把公司拖死的事。
3. 大牛，可以白板水笔写项目一遍过无 bug 的人。

我自己的业余项目基本上都有测试，主要做集成测试。
公司项目也都有测试，测试覆盖不够的话 code review 也过不了。

@superrichman 写好了就不会改的东西反而是不怎么需要单元测试。单元测试一个重要的作用就是保证迭代中的改动不会 break 旧的逻辑。

@varrily 怎么感觉咱俩是在一个团队的呢，哈哈哈哈

@y2xworm 我是通过单元测试保证功能稳定的。没有单元测试，我都不敢做太大的迭代、重构。每次 git commit, 默认都要在 pre-commit 走一下 unittest(可以只测试修改过的目录)才会放心。
-------------

你们的 UnitTest 应该是测试的输入、输出吧。

你们修改核心的功能，有影响到输入输出吗？如果影响到了，说明你们修改属于 break changes （这是可接受的）. 否则就是你们的设计存在问题
------------
我的体会是：
1. 单元测试的 mock 需要好的框架设计、也需要一些技巧和技术，这个话题可以展开说
2. 单元测试不必追求覆盖率、不必追求完全的 mock ，但是新增修改、核心代码，应该尽量覆盖

我手里有个线上业务的 node server ，搞不好会导致 app 崩溃那种，但是不可能我每次改动就让 QA 给测试，所以只能补充单侧，然后每次改动后跑跑单侧；否则靠人肉测试 会崩~

国内公司搞业务的状态,其实做不了单元测试. 首先是时间上, 没有给开发人员写单元测试的时间, 一个合格的单元测试, 测试用例, 覆盖率, 部分简单业务来说, 可能写业务 30 分钟, 单元测试得 1 个小时或者更多.
另一个就是国内业务需求变动太大, 如果需求频繁变动, 导致的是单元测试得重写. 单元测试的一个目的是, 相关业务变动时, 复用单元测试保证之前的测试用例能通. 这是矛盾的.

很多人觉得写测试做 TDD 会延迟交付。。。其实恰恰相反，就算不考虑自动化测试带来的长期价值，哪怕只是一次性的也比正常写代码更快。前提是架构足够整洁，易于测试，和开发人员知道怎么写真正跟实现解耦的测试。
所以 TDD 要真正落地并不容易，往往需要团队里有真正懂这个的 Teach Leader 来负责

真正的测试驱动开发，是可以利用测试用例一步步推演出代码实现的，比正常写代码更快
感兴趣的可以参阅《匠艺整洁之道》或者极客时间上找找测试驱动开发的课程
另外 ATDD 和 UTDD 是两种不同的模式，要根据工程业务复杂度和实际情况选择占比，通常来说如果业务非常复杂我更推荐 UTDD ，可以大幅加快开发实现速度

如果架构足够整洁，可以让领域层的业务逻辑代码完全跟外部依赖(其他服务和数据库，MQ 等)解耦

我们这里后端开发是这样做的，写业务代码之前先写好主要的接口，和单元测试，interface 和 unit test 的 pr review 过之后，才允许提交业务代码，业务代码实现的 pr 需要贴前面两个 pr 的链接并通过测试。
不过对管理者考验也是很大的，需要有一个看到需求就能有大概框架的 tech lead ，否则就会陷入反复修改 interface 和 unittest 的死循环。

最好的办法还是团队建立的时候就规范好开发流程。团队和代码成型后再想推测试是很难的。因为很多代码的结构可能根本就无法测试

我们从源头上抓起， 招聘的代码测试环节就有要求写测试代码，不写测试大概率是招不进来的。
进来后鼓励采用 TDD 方式开发，不写测试代码没人给 review PR ，就 merge 不回去主干分支，然后 CI 也会检查覆盖率。
之所以一直这么做，是团队真的获得了巨大收益（低缺陷率，低耦合模块结构，可以大胆重构 /加功能等等）
https://github.com/Wiredcraft/test-backend#functionality

看项目

如果需求经常变化，或者项目周期非常短，没有写单元测试的必要

有

为了单元测试而写单元测试是没有意义的。
业务 => 功能代码 => 单元测试 ：这里的单元测试是测试的代码逻辑并不是测业务。
业务 => 单元测试 => 功能代码：这里的单元测试是基于你对业务的理解写出来的，测的是业务。

TDD 对于我来说，最大的收益就是信心，勇气，还有 context

取决于需要速度还是需要质量