作者HZYSoft (PCMan)
看板Soft_Job
标题Re: [讨论] 怎样算是一个合格的junior cpp programme
时间Wed Aug 24 22:17:41 2022
针对关於 TDD 的讨论另外回一篇好了
觉得用推文太长了 XD
: 推 stupidlove0: 朝圣！重要的真的是unit test 08/23 18:47
: → HZYSoft: 回楼上 TDD 问题，TDD 不只要测试，还要先写测试才写code 08/23 21:33
: → HZYSoft: 很多人无法习惯这种顺序，是否一定要 TDD 这有争议 08/23 21:34
补充一下，TDD 是还没有开始写任何的 code 之前，就先针对
程式写好之後 "预期应该要有的行为" 先写 test cases
接着，先跑一次测试亲眼看着他 fail
因为还没写任何 code，所以测试绝对会 fail，
如果没写 code 却 pass 那表示你的 test case 根本没有测到。
接着才开始写 code，重复跑测试直到确认 pass 为止，就是完成了。
不同於先写 code 再测试，TDD 是颠倒，先测试再写 code，所以才叫 test driven
如果程式被报 bug，也是先写一个会 fail 的 test case，确认可以重现 bug
接着才开始改 code 修正，直到测试 pass 为止，就表示修好了。
这是一个观念很特别的流派，他们的主张都是有道理的，就只是比较违反直觉不好实现。
如果你无法先写出测试，那表示你还没弄清楚要实作什麽行为，
或是你原先构思的 API 介面难以使用，以至於你写不出 test case
这是强迫你厘清 spec 以及设计好介面的方法，但实在有点极端，被不少人视为邪教 XD
: 推 TeaEEE: TDD最大的阻力来自你的老板 08/24 11:40
Testing 相关的东西常常是这样，因为一开始看不到立竿见影的成果，
花掉的资源，也没有立刻转成给客户的价值，跟下水道工程一样重要但看不见。
: 推 wulouise: TDD在需求不明确的时候写会很痛苦，SPEC改testcase全改 08/24 12:43
: → wulouise: 但只有一个test, 还是可以加快开发的iteration, test编 08/24 12:46
: → wulouise: 译执行时间通 08/24 12:46
: → wulouise: 通常比跑production快很多 08/24 12:46
这个事情我觉得不是 TDD 的锅，需求不明确本身就很痛苦，TDD 只是让你提早面对它
需求不明确或是改来改去，你连 code 该怎麽写，写出来该有什麽行为都不知道
自然是无法写出 test case 的。但反过来说如果状况是如此，你写出的 code 会对吗？
错是错在没定义清楚程式行为，不是 TDD 的错。
TDD 只是一面镜子，让你提早发现问题，事实上这是好事。
表面上测试写得很艰难拖慢进度，实际上是反映团队沟通不良，和需求不清的问题
我们应该解决问题，而不是解决发现问题的人(跳过测试不做)
如果放弃做测试来节省时间，做出问题一堆的产品，这些时间後面也是要加倍还...
但也有情况例外，就是做 MVP 的时候。还来不及做测试，产品就被取消了，就免还债 XD
: → foreverk: TDD比较可怕的是工程师还没掌握domain，写出不合理的te 08/24 14:04
: → foreverk: st case，而且自己不知道 08/24 14:04
这或许不是 TDD 的锅，domain 掌握不足，设计出来的 API 多半也会是有问题的，
TDD 并没有让事情更糟，只是强迫问题更早浮现罢了。
说了半天整篇都在帮 TDD 护航，但我自己大多是没在用 TDD (汗颜...)
主要原因还是真的很难习惯，而且经验比较不足，有时候 API 设计也是 try & error
虽然整个软体巨观该有什麽行为已经订出来了，但程式会拆成很多小模组
每个模组该有哪些行为，完全端看你怎麽拆，而很多时候就是这点难以决定，
需要稍微实验不同的作法，在这个阶段强迫要先写 test 还真有点强人所难。
但如果是定义很明确的 API，例如 web 後端的 RESTful API，介面都已经订好了
这时候遵循 TDD 先写 test case 完全是可行的，有兴趣的朋友不妨一试!
--
Sent from PCMan on PCMan's PC
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.249.189.4 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1661350664.A.083.html
※ 编辑: HZYSoft (111.249.189.4 台湾), 08/24/2022 22:22:04
1F：推 windclara: 想问若是前端的话，该怎麽TDD较适合呢？观念都理解， 08/24 22:24
2F：→ windclara: 但在前端常常写一写又拆出子组件… 08/24 22:24
3F：→ HZYSoft: 抱歉这个我无法回答，我自身经验也不够 XD 08/24 22:27
4F：→ HZYSoft: 虽然我能理解也算认同TDD的理念，但也没办法真的掌握它 08/24 22:27
5F：→ HZYSoft: 应该不少人觉得实行起来困难，所以批评声浪也没停过 08/24 22:28
6F：推 linnom: 笑死 “Sent from PCMan on PCMan's PC” 08/24 22:31
7F：推 shibin: 推，最近写UT也是很苦手，很高兴可以看到此类讨论 08/24 22:36
8F：推 iankingh: 推 08/24 22:57
9F：推 wulouise: 越靠ui的通常越难写写UT...至於规格不明确的确是不该怪T 08/24 23:31
10F：→ wulouise: DD, 只是不明确的时候应该先弄清楚再来写XD 08/24 23:31
11F：推 holebro: 好想进去有走TDD的公司 感觉好赞 08/24 23:36
12F：推 wulouise: 说真的有unit test就很好了，100%TDD执行面有困难 08/24 23:52
13F：推 viper9709: 原来是这样~感谢分享 08/25 00:16
14F：→ sevenHEAD: 前端大概或许用testing-library那种测法，内部你怎麽 08/25 01:28
15F：→ sevenHEAD: 拆不管 08/25 01:28
16F：→ foreverk: 同意TDD是让问题提早浮现，尤其edge case可能是使用到 08/25 08:53
17F：→ foreverk: 其他api时才会发现的，不过通常需求会一环扣一环，团队 08/25 08:53
18F：→ foreverk: 其他人可能宁愿你先写个可以跑的东西让他可以接下去， 08/25 08:53
19F：→ foreverk: 而不是等到TDD流程都走完，要求团队都有单元测试都有点 08/25 08:53
20F：→ foreverk: 难了，还要大家都TDD实在无法想像XD 08/25 08:53
21F：→ Wishmaster: 单元测试不是放在重点服务及重点功能上吗? 08/25 11:12
22F：→ Wishmaster: 真的有公司所有的程式都写UT吗? 实务可能吗? 08/25 11:12
23F：推 vi000246: TDD很难的原因有可能是需要重构到很精简没有相依 08/25 11:29
24F：→ vi000246: 才能写出有效的测试 在开发阶段写UT就没什麽时间了 08/25 11:30
25F：→ vi000246: 更何况要重构 以及担负重构衍生出的问题责任 08/25 11:30
26F：推 superpai: 你写的任何程式不测试怎麽知道对不对，你把写console lo 08/25 11:43
27F：→ superpai: g跟用眼睛看结果的时间拿去写 unit test就好了 08/25 11:43
28F：→ DrTech: 一般真正能落实的公司，就是考管理政策推动。线上出现Bug 08/25 12:32
29F：→ DrTech: ，不同等级，对於考绩的影响是什麽，导致Unit Test，cover 08/25 12:32
30F：→ DrTech: age，增量覆盖率，都有规范，避免出大错。有了管理与考绩 08/25 12:32
31F：→ DrTech: 支持，TDD就变成增加效率的优势了。 08/25 12:32
32F：→ DrTech: 没靠管理支撑品质，人都说有惰性的，绝对不觉得TDD多重要 08/25 12:33
33F：→ DrTech: 。 08/25 12:33
34F：推 art1: 结果是一张图的时候应该没办法很难测吧 08/25 15:50
35F：→ art1: *应该很难测 08/25 15:50
36F：推 testPtt: 面对随时有陨石会砸下来的情况下TDD有用吗? 08/25 16:00
37F：推 lovdkkkk: 其实越常变化或扩展测试的用处越大，不过跟 TDD 较无关 08/25 16:18
38F：→ lovdkkkk: 有写就有用，不一定要 "先" 写 08/25 16:18
39F：推 CRPKT: TDD 可以提早验证 API 的使用性有没有缺陷 08/25 16:46
40F：→ CRPKT: 但并不是 API 漂亮就不会在架构上遇到问题 08/25 16:46
41F：→ CRPKT: 有时候两边都要顾一下会比较平衡 08/25 16:47
42F：推 henry4343: 好奇真的有办法先写好unit test在开始写程式吗？ 08/25 21:05
43F：→ henry4343: 很多unit test都是在assert function 没function的话 08/25 21:05
44F：→ henry4343: 没function的话要怎麽compile过呀 还是是说function先 08/25 21:06
45F：→ henry4343: 宣告但内容不写 然後先写测试这样吗？ 08/25 21:06
46F：→ HZYSoft: 极端一点没 function 直接写测试也可以，要确定他会 fail 08/25 21:11
47F：→ HZYSoft: 当程式有 #ifdef 的时候确实可能有些 code 根本没 build 08/25 21:11
48F：→ HZYSoft: 所以从头到尾测试根本没 build 到，先确定会 fail 有帮助 08/25 21:12
49F：→ HZYSoft: 或是像 python，没定义 function 也能跑 runtime 才失败 08/25 21:13
50F：→ HZYSoft: 这种也可以先跑看看确定他会 fail，确认 test 真的有执行 08/25 21:13
51F：→ HZYSoft: 我自己真的有遇过 test function 没跑到，结果假性 pass 08/25 21:13
52F：→ HZYSoft: 原因是我把 function name test_xxx 拼错成 tset_xxx 08/25 21:14
53F：→ HZYSoft: 於是 python 的 unit test 没抓到这个 test function 08/25 21:14
54F：→ HZYSoft: 怎麽跑都 pass，因为根本就没测到。所以不要觉得这很多余 08/25 21:14
55F：→ HZYSoft: 或是先写个空的 function，跑看看确认他真的会 fail 08/25 21:15
56F：→ HZYSoft: 这算是 TDD 一个重要的观念 08/25 21:15
57F：推 wulouise: 真的要先fail才有办法确定他是有用的XD 08/25 21:24
58F：→ wulouise: 我有遇到test永远是对的 里面对不对根本不知道 08/25 21:25
59F：→ wulouise: 还有根本不存在资料被判断存在，因为跟其他资料重复XDD 08/25 21:25
60F：推 mmonkeyboyy: 你有规格书就能先写啊 没有就只能边做边摸索 08/26 04:33
61F：推 CYHyen: 其实想起来也没那麽邪，就像刷题，也是test先写好等你 08/26 09:46
62F：推 zebraseven: 好 08/26 12:44
63F：推 SHANGOYANYI: TDD难在要想出各种案例XD 08/26 21:11
64F：→ bnd0327: TDD在做自己私人专案的时候比较好用，因为自己写的本来就 08/30 14:38
65F：→ bnd0327: 比较随兴，用TDD方法一步一步做比较不会放飞自我 08/30 14:40
66F：推 akira01: 个人的经验,一堆人在等你的code才能继续下去,一个礼拜过 09/02 07:20
67F：→ akira01: 去了,这时只说我由於用tdd只完成了测试程式,会遭人白眼, 09/02 07:20
68F：→ akira01: 所以通常我们还是会先完成功能再补测试程式 09/02 07:20
69F：推 superpai: tdd是测试跟实作交替写，会说测试先写完就是做错了 09/02 07:35
70F：→ HZYSoft: 测试先写是针对要改动的地方，不是整个系统都只先写测试 09/02 21:47
71F：→ HZYSoft: 实务上确实是交替进行没错 09/02 21:47
72F：→ longlongint: TDD不会升迁啦，写烂code升迁学弟接手赞赞（反串） 09/11 20:49
73F：推 jackhsien: 个人经验TDD 适合需求明确的开发 不然光改测资就耗掉一 09/16 10:44
74F：→ jackhsien: 堆时间 09/16 10:44