关于 TDD 个人一点看法
我觉得 TDD 最大的用处是让你 "做一下，想一下"，
这件事本身就很有用，相信有不少人有类似经验，
很快想到一个版本，在几个循环后陆续想到 3~5 个改版，
其中则有某个版本特别好实作，可以用初版 1/5 以下的时间完成，
复杂度也更低，更干净有弹性
另一个很好用的情形是以更小的粒度当成一个 "完成" 的状态，
一般是做完测好确认功能无误后再整理程式，
若做的东西较大较复杂则可能要几天到几周才会到完成，
那时再整理会较麻烦，也较容易出错要再多重测几次，
用 TDD 的话则不必等到整个完成，中途觉得哪里怪怪的想调一下随时可以调，
且调完几秒内可确认没有改坏，
只要不要太钻牛角尖浪费太多时间过度设计过早优化的话就好，
然后我觉得不一定要很小很干净才能做 TDD，
就算是很大粒度的 E2E api 测试也有不错的效果，
真的很细小单纯的东西个人倒觉得不太需要使用
另外我觉得 TDD 算是很工程师的工具了，
它只关乎你怎么进行 development 的工作，
就像要用哪个 ide 或用什么键盘差不多的概念，
用得顺手，用起来不会影响工作，自己想用就用即可
初期学习研究工具跟尝试工作流会比较花时间，
上手后大概知道自己用得顺手的情况再适时去使用也就只是几分钟的事情
另外个人觉得可以不用完全遵守 "先/后" 次序，
中途某个段落先开发 3 分钟，开发到一个段落再补相关测试，
我觉得并不会真的有什么差别，最大重点的 "做一下，想一下" 并没有被破坏，
也仍然在补完测试后可很快验证程式
然后其实也不用花太多心思在想 test case 上，
可以先有基本的测试就好，不用一开始就想很多 case 很多细节
举一些近几个月的实例，
大概二月在做一组服务相关 API，就是先有 API 测试再开始做，
这让开发验证流程非常快速，
自动测试 watch 开着，开发中途存盘完看一下旁边的 console 就知道状况，
不用切到浏览器打 API 再切回来
前两个月在做一个较复杂的东西，大概像是服务合约的底层核心之类的东西，
因为觉得较大较复杂希望能在开发中有较即时的回馈故使用 TDD，
然后做着做着在中途发现没注意将两个相同性值的资料以不同的型态储存，
想将它们的型态改成一致的
使用 TDD 让我能很安心的放手去改然后跑测试
上面这过程我有拍影片给公司其他人看，
后来 react-native 的前端工程师也有用，
若能把逻辑跟 view 切开那测试方式基本差不多，
如果混在一起那可能就要借助一些像 jsdom 之类的工具
※ 引述《NDark (溺于黑暗)》之铭言：
: ※ 引述《HZYSoft (PCMan)》之铭言：
: : 补充一下，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
: 推文看到有人问前端.
: 我个人是做客户端所以很多传统的测试方法论对接口其实效用很低.
: 上述段落让我想起以前写作的经验.单纯分享.
: 我在2018~2020年在阿布达比UB维护手机线上游戏Growtopia.
: 当时的案子有很多骇客想要破解我们的游戏的攻击行为.
: 当时的主程式教给我一个我以前没这样试过的技巧.
: (但我必须强调.这整个系统跟时程就是不允许我们重构.
: 所以也不可能有什么有序的测试方式.
: 功能($$$)产生的速度就是比测试码(COST)来得快
: 该专案几年的程式码简单来讲就是靠优秀的程式员无止尽的缝补.)
: 不过.当我分享给同僚的时候.他们都给我一种我在讲什么歪理的眼神.
: 简单说
: 我们当时遇到很多透过奇妙行为(譬如说破解封包)来try我们游戏server的行为.
: 因为那些行为不是正规动作.所以我们的QA部门无法用正规手段重现这些步骤.
: (当然终归到底就是没有那么多时间/资源
: 去真的学着逆向重建一个骇客软件
: /线上的问题就是以天为单位要解掉)
: 所以我们无法知道这些破坏到底起因如何.(来龙去脉/窜改点)
: 我们只能够知道具体来说发生破坏的时间点.(ex.爆炸点/因为有exception log)
: A) 爆炸点 已知爆炸发生了.程式码假如这样:
: {
: Func1();// 我们只知道这函式进去的特定一行发生爆炸(ex. null reference),
: // 而函式发生前server环境就已经被窜改/攻击为会爆炸的情况
: }
: B) 埋点: 制作一个骇客的模拟入口
: {
: DEBUG_HACKER_ACTION(); // 制作一个入口,
: // 我们猜测并刻意模拟骇客的行为就是会把上述那个会爆
: // 炸的某个内存抹掉.
: Func1();
: }
: C) 用后门指令手动触发埋点 DEBUG_HACKER_ACTION() : OK 现在可以重现骇客的爆炸了.
: (红灯)
: D) 修复: 在Func1()里面布下重重安全机制.只要有异常就吐LOG然后封锁该玩家(强制离
: 开/行动取消/黑名单,etc)
: E) 这步骤最重要.再次用特殊指令手动触发埋点DEBUG_HACKER_ACTION() : OK server安
: 全了.Log正常吐出. (绿灯)
: F) 把后门指令+埋点mark起来.上线测试.抓有问题的玩家.封号.
: G) 这步也很重要,如果之后又发生类似的问题.再把后门指令搬过去开起来用.快速触发错
: 误.同时也可以确认之前修掉的问题没有再出现.
: 好像不是什么很玄妙的高招.
: 但是面对一些客户端/前端无法重现
: (譬如说一秒钟按钮连打60下这种不可能正常可以达到的行为所触发)的问题.
: QA又两手一摊没办法重现只好自救的时候,不失为一个方法.