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