列了 Pros (一行) 跟 Cons (超長 XDDD)：
- We end up with tests that verify the behavior of the code and help prevent regressions
這個是 TDD 的目的。而 Cons：
- It takes us longer to write code using TDD
- The tests get in the way. Because my design does not have low coupling, I end up with tests that also do not have low coupling. This means that if I change the behavior of how class
works, I often have to fix tests for other classes.
- Because I don’t have low coupling, I need to use mocks or other tests doubles often. Tests are good to the extent that the tests use the code in precisely the same way the real system uses the code. As soon as I introduce mocks, I now have a test that only works as long as that mock faithfully matches the behavior of the real system. If I have lots of mocks – and since I don’t have low coupling, I need lots of mocks – then I’m going to have cases where the behavior does not match. This will either show up as a broken test, or a missed regression.
- Design on the fly is a learned skill. If you don’t have the refactoring skills to drive it, it is possible that the design you reach through TDD is going to be worse than if you spent 15 minutes doing up-front design.
這四個問題講的是時間與能力兩個因子的作用，轉一個角度來討論其實是：如果 junior engineer 可以寫出好的測試，他們就不叫 junior engineer 了... 而 senior engineer 是稀缺資源，讓他們多花時間寫出「好的測試」未必是划算的。
反而是另外一種常見的方式常常跟 TDD 在對抗：透過 QA team 在完成後測試，尤其是用手動測試的 QA team XDDD
這個方法很簡單，而且行之有年。而且很無奈的，跟一般軟體工程所期望的相反，junior engineer 就可以做的不錯，所以人力的部份相當好 scale，而品質也有不錯的水準 (畢竟是直接測實際的功能了)。
剛好前陣子有提到另外一篇論文也在討論 TDD 的效果 (參考「又一篇戰文：討論 TDD 的過程」這邊)，也有類似的反思。
前陣子在 Twitter 上看到這則也是很有趣，拿來當結尾 XDDD：
爛 code 在經過長時間的演化之後，就會變成穩定的爛 code：不只爛，而且比任何試圖改進的版本穩定。
— Shiao-An Yuan (@shiaoanyuan) February 22, 2016