Kinderman和一些rails開發者交談中，問他們使用什么樣的方法，是自底向上的TDD呢，還是自頂向下的TDD？他期望每個人都從自頂向下——也就是說，從需求開始，為需求寫測試，然后構建一個系統來滿足且僅滿足這些需求（這也就是行為驅動開發（BDD））。但令他驚訝的是，他發現幾乎所有人都采用從底向上的方式。
“自底向上”這種方式存在的問題是：直到實現了調用者（clients）后，才知道這個調用者真正需要什么組件。而為了實現這些調用者，開發人員還要想這些使用者是如何被它們的調用者所使用的。這使我們會一直追溯到設計的頂點！真希望開發者深思熟慮以后，他們能寫出一套完整的測試，來測試那個能夠直接解決調用者需求的組件。但是，根據我的經驗，這是非常罕見的。事實上，對于它的調用者來說，這些低層組件實現的功能很難用，要么太多，要么太少，要么太笨拙，要么太復雜。
正如Ryan所述，這似乎是要么都做，要么都不做�？墒�，另外一些人寫功能測試（或自動化驗收測試）也有很長時間了，而且是先寫測試。這種方式有時被叫作故事驅動開發，測試驅動需求（TDR）,或行為驅動開發（BDD）。那些使用測試驅動開發（有自底向上的，也有自頂向下的）來實踐這種方式的人發現，這樣不僅提高質量，而且有助于在客戶、開發人員和測試人員之間建立社會性文化。
那么，你怎么做TDD呢？你用自頂向下方式，還是自底向上？你的團隊用TDR嗎？你用哪種方式呢？還是兩種都用？最重要的一點，你這么做的目標是什么？
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/