因为测试相对来说会比较机械化，简单一点，比较适合不想写代码的时候维持低程度的日常输出。但同时测试用例又可以让对代码的理解程度不至于过于生疏。
（只是一个想法而已，因为最近确实感觉不太想写东西，就在想是不是可以通过写测试来绕过这个低谷期）
（只是一个想法而已，因为最近确实感觉不太想写东西，就在想是不是可以通过写测试来绕过这个低谷期）
 |
1
kikoroc 6 天前 via iPhone
是的，可以把逻辑在脑子里过一遍
|
 |
2
dawn009 6 天前
值得尝试
|
 |
3
securityCoding 6 天前 via Android
恭喜你抓到了本质
|
 |
4
sillydaddy 5 天前
不错的想法。好像除了写测试用例稍微轻松点，程序员平时的工作就都是耗费脑力的编码了。
|
 |
5
hellohido 5 天前
是这个意思呢。
|
 |
6
mobpsycho100 5 天前
还有一个用处是测试可以拿给 LLM 生成代码. 不过很多时候其实在代码写出来之前谁也不知道结果应该长什么样.
|
 |
7
SenseHu 5 天前
无法自动化测试的架子，不是好架子
|
 |
8
kenshinhu 5 天前
测试驱动开发可否快得过产品经理的变化？
|
 |
9
liununu 5 天前 via iPhone
之前想到过一个比喻，就是小时候玩过的数字连点画
|
 |
10
zhouyin 5 天前
天下还有喜欢测试的 双倍的工作量
|
 |
11
guiyumin 5 天前
我遇到的代码分为三类：
1. infra 代码，这个要求稳定性，测试必须 100%覆盖，而且除了 unit test ，还要有各种其他测试来保证代码的可靠性 2. 业务代码，这个就很扯淡了，有一些业务代码是很稳定的，有些业务则经常变，所以这里的测试，其实就是见仁见智，但为了让你不要半夜被吵醒修 bug ，我觉得还是多一些测试比较好，不一定是 unit test ，而是让你能感到放心的测试 3. 一次性代码，这个就是图快，所以没有测试很正常，但你自己得看一下，当然了，这些代码通常也不重要 |
 |
12
netabare OP @SenseHu 这玩意本身也是很模版化的吧，自动化本身倒也没多难
@sillydaddy 确实是这样 @kenshinhu 我自己的项目里面就没什么产品经理可言了…话说过来哪怕生产项目，也总有相对稳定可以提出来测试的部分吧？ @zhouyin 并不会，就像上面有个评论说的，测试本身都是自动化的。我想说的「写测试」更多是说一些测试用例或者构想可能的使用场景，这些东西算是我可以比较容易地去想很多的东西（不写代码的前提下） @guiyumin 认同，三类代码的划分法也基本上是我的思路 |
 |
13
Salticey 4 天前
之前有读过一本书就是《测试驱动开发》，不过没细读，不知现在这个理念是否有过时之嫌？
|
 |
14
CassianVale 4 天前
什么是测试驱动开发
|
 |
15
soya2 4 天前
先写测试用例再写实现能保证健壮性，但在商业上成本略高了，尤其是快速迭代的产品，后期也许维护测试用例的时间远远大于开发的时间，老板一般不会接受
|
 |
16
jetflyL 3 天前 via Android
写了接口和测试调用断言，运行失败的，后面要做的就是填代码让测试通过
|
Select Language