针对关于 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 完全是可行的，有兴趣的朋友不妨一试!