突然想到，测试驱动开发是不是有一个用处是「不想写代码的时候可以先把结构打好」

是的，可以把逻辑在脑子里过一遍

值得尝试

恭喜你抓到了本质

不错的想法。好像除了写测试用例稍微轻松点，程序员平时的工作就都是耗费脑力的编码了。

是这个意思呢。

还有一个用处是测试可以拿给 LLM 生成代码. 不过很多时候其实在代码写出来之前谁也不知道结果应该长什么样.

无法自动化测试的架子，不是好架子

测试驱动开发可否快得过产品经理的变化？

之前想到过一个比喻，就是小时候玩过的数字连点画

天下还有喜欢测试的 双倍的工作量

我遇到的代码分为三类：

1. infra 代码，这个要求稳定性，测试必须 100%覆盖，而且除了 unit test ，还要有各种其他测试来保证代码的可靠性
2. 业务代码，这个就很扯淡了，有一些业务代码是很稳定的，有些业务则经常变，所以这里的测试，其实就是见仁见智，但为了让你不要半夜被吵醒修 bug ，我觉得还是多一些测试比较好，不一定是 unit test ，而是让你能感到放心的测试
3. 一次性代码，这个就是图快，所以没有测试很正常，但你自己得看一下，当然了，这些代码通常也不重要

@SenseHu 这玩意本身也是很模版化的吧，自动化本身倒也没多难

@sillydaddy 确实是这样

@kenshinhu 我自己的项目里面就没什么产品经理可言了…话说过来哪怕生产项目，也总有相对稳定可以提出来测试的部分吧？

@zhouyin 并不会，就像上面有个评论说的，测试本身都是自动化的。我想说的「写测试」更多是说一些测试用例或者构想可能的使用场景，这些东西算是我可以比较容易地去想很多的东西（不写代码的前提下）

@guiyumin 认同，三类代码的划分法也基本上是我的思路

之前有读过一本书就是《测试驱动开发》，不过没细读，不知现在这个理念是否有过时之嫌？

什么是测试驱动开发

先写测试用例再写实现能保证健壮性，但在商业上成本略高了，尤其是快速迭代的产品，后期也许维护测试用例的时间远远大于开发的时间，老板一般不会接受

写了接口和测试调用断言，运行失败的，后面要做的就是填代码让测试通过