在企業向敏捷轉型的各種實踐中，TDD通常是最艱難的一個。
這對美國猶他州Midvale的IBM軟件組來說是確確實實的體驗。他們從2007年就開始向敏捷轉型。IBM開發轉型部門副總裁Sue Mckinney認為，測試驅動開發前景非常誘人，但是“在這個過程中我們的付出可能也是最多的�！�
Mckinney說：“雖然我們做了大量的自動單元測試和功能測試，集成測試也做得越來越好，但是這畢竟是一種意識問題。開發人員喜歡編寫代碼，他們一點兒也不喜歡做測試�！�
她又補充道，但這是他們必須經歷的一段旅程，“我們通過兼并獲得一些優秀的設計師，他們在TDD方面有很不錯的經驗，值得我們效仿。我們請他們將經驗和大家分享。這將是我們2009年的重點工作——讓我們的團隊學習TDD�！�
TDD根源于極限編程（XP），通常指開發人員在編寫代碼之前創建用于對代碼進行自動單元測試的實踐。Kirk Knoernschild是Burton集團的一位分析師。他列舉了這個過程中所面臨的挑戰：“如果單元太大就很難寫出高質量的測試。并且，雖然許多組織都說他們的開發人員在寫單元測試，但是實際上他們也不知道自己的代碼覆蓋率有多高。還有許多組織仍然會把測試階段推遲到軟件周期的后期，這無疑會使問題變得更嚴重�！�
舊代碼也會產生問題。據AMS Services的首席架構師Chris Kinsman說，雖然AMS已經提高了對代碼的單元測試和集成測試的力度，但是他們并沒有做太多TDD方面的工作�！拔覀儸F在有大量的非TDD代碼。舊代碼幾乎沒有測試驅動的�！盋hris表示，“部分團隊做過TDD方面的短期努力，但那不等于在全部團隊都采用了這個實踐�！�
他認為，AMS不一定會把TDD作為目標，“我擔心我們的代碼基礎可能不支持這么做。在走這一步之前，我們還要先解決一些架構上的問題。我并不是從理論上反對這么做，我只是不想把我們當前的工作弄得更辛苦而已�！�
Knoernschild認為，測試驅動開發所面臨的另一難題是它給人一種會減緩開發團隊速度的感覺。復式記賬法就是一個很好的類比。如果會計不使用復式記賬法，那么他的工作會快很多。但是這樣的結果就是一旦出錯他無法（輕松地）使用制約系統進行檢查。測試也是如此。一旦出現了問題，你會發現你缺少相應的制約系統來檢查并確定問題的根源所在。
雖然TDD確實會減緩工作速度，但是長遠看來，“隨著代碼的增長，它實際上是會提高速度的�！�
Forrester的分析師West認為，這是一種文化上的轉變，“以前的軟件工程師在拿不定主意的時候會寫許多文件，但是這些文件都沒有說到痛處。因為這時候沒有讓你戰勝這個問題的環境，缺少的是一種氛圍�！�
West還說道，開發人員在寫測試之前可能需要先研究一些東西，“并不是說你不喜歡這種方式，而是在你寫出一部分編碼、了解到一個大概之前，你無法真正地明白問題，也就無法寫出測試來。而在敏捷所提倡的探索性過程中，你可以更好地了解問題所在，相應地也就會更習慣于這種做法�！�
West認為，測試資源按部門劃分的方法也是一個障礙，“某些供應商要為此負責，因為他們鼓勵卓越中心的做法——即專門負責QA的部門。這使得很難從早期就開始QA方面的工作，所以你只能在沒有QA的情況做敏捷工作。你確實會做單元測試，但是你把它和其它工作分開了，因為它們屬于不同的部門�！�
網絡內容管理公司Vignette已經開始接受TDD，但也只是剛開始。其工程部主任Subu Subramanian說，“如果團隊考慮了需求描述和驗收標準，他們會把這些詳細地寫到測試里，這樣他們在進行設計和開發的時候就會同時考慮測試�！彼硎�，Vignette的最終目標是把測試帶入到開發周期的早期階段。
雖然這不是敏捷的一部分，卻可以為測試驅動開發帶來意想不到的效果。他說，“雖然TDD通常會和敏捷開發聯系在一起，也是敏捷實踐的一種，但是即使你沒有把全部精力都投入到敏捷當中，TDD的價值也是顯而易見的。從你寫下第一行代碼的時候，你就可以把測試帶入開發周期。你可以在編寫代碼的同時生成相應的測試集�！�
他還補充說，“如何執行TDD取決于你的企業結構。你必須根據實際情況做決定。比如可以是一種兩人工作的模式，一人寫測試，一人寫代碼�！�
不管TDD將來如何發展，各企業都需要“盡可能地在早期階段把盡量多的精力放到質量與測試當中”。
文章來源于領測軟件測試網 http://www.kjueaiud.com/