測試優先和單元測試在XP中屬于同一個實踐，但是它們仍然是由區別的。測試優先強調行為，在寫代碼之前寫測試，單元測試主要指的是測試的范圍或級別。我們說，測試優先實踐真正關心的，并不是測試是否要先于代碼，關鍵在于你是否能夠編寫出適合于測試的代碼，是否能夠從測試的角度來考慮設計，考慮代碼。 從另外的一個角度上說，堅持測試優先的實踐，可以讓你從一個外部接口和客戶端的角度來考慮問題，這樣可以保證軟件系統各個模塊之間能夠較好的連接在一起，而開發人員的思考方式，也會逐步地從單純的考慮實現，轉移到對軟件結構的思考上來。這才是測試優先的真正思路。而堅持先寫測試，只不過是幫助你轉變思維習慣的一種措施而已。對于一些優秀的程序員來說，只要能達成目的，是否測試優先，倒并不是最關鍵的了。
其實做測試是一件很難的事情，因為很多時候，我們不能夠完全的模擬出測試環境，或者是完全模擬出測試環境的代價太高。軟件開發總是在一個固定的時間和成本的前提下進行，因此我們必須盡可能用小的成本來達成我們的關鍵目標。很多關于測試的書中都提到諸如磁盤出錯之類的錯誤是很難進行測試的，但實際上，還有很多很多的內容是難以進行測試的。例如，一個業務邏輯，它使用到了14個業務實體和其它的一些配合的類，如何測試它？使用Mock Object方法，建立測試Fixture的代價將會很高，此外，如果實體類是可以控制的（例如，該實體類可以使用程序來初始化數據，而不是從數據庫中獲取數據），這個測試的成本還可以接受，如果不是（例如，第三方提供的技術），這個成本將會更高。類似的情況還有很多，但是為什么會出現這些問題呢？其中一個很大的原因就是我們并沒有真正的把測試作為軟件開發的一個重要的組成部分， 堅持測試優先的思考方式，可以大幅度的降低測試成本�，F代的軟件開發往往都依賴于特定的中間件或是開發平臺，如果這些第三方產品沒有提供一個強大的測試機制的話，要對最終的產品進行全面的測試往往是很難的。例如，在J2EE提供的Jsp/Serverlet環境，模擬Http的輸入和輸出是一件很難的事情。如果在軟件設計階段不考慮測試，那么最后的測試將會是寸步難行的。但是實際上，如果在軟件設計時考慮到測試的困難程度，并將業務代碼和環境控制代碼區分開發，使之彼此之間沒有過大的耦合。這樣，測試工作就可以針對獨立的業務代碼進行，而這個成本就會低很多。
public class UserLog
{
public Service()
{
//難以進行測試的代碼
//需要測試的業務代碼
}
}
文章來源于領測軟件測試網 http://www.kjueaiud.com/
