測試驅動開發（TDD)引發的爭論

這是一篇來自於 import new 的探討： 測試驅動開發（TDD)引發的爭論,
還有 Kent Beck 在 StackOverFlow 的解釋:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it. I do tend to make sense of test errors, so I'm extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.

Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. Ten or twenty years from now we'll likely have a more universal theory of which tests to write, which tests not to write, and how to tell the difference. In the meantime, experimentation seems in order.

我自己覺得, 測試價值不應該著重在追求覆蓋率, 而是減少高複雜度的代碼出錯的機會, 應該是上面這段話的核心價值, 另外在團隊合作開發的過程中 TDD 也是讓合作人員快速了解某些模塊的功能, 在 code Reveiew 之後多建立一道防線來保證代碼的品質。