對於tdd的「單元測試」與傳統的「單元測試」之間的差異，業界一直存在著誤解。知名的xp貢獻者mike hill，對這些誤解進行了澄清。他還特別講述了在industrial logic的經歷，在那裡展開教學時，他和其他人一起使用「微測試（microtests）」這個詞彙來指代tdd的單元測試，避免產生「單元測試」概念上的混亂。
我們將xp中的單元測試稱為「微測試」，因為之前總是要跟別人解釋xp的的單元測試跟傳統意義上的單元測試的不同，既繁瑣又容易出錯。這樣命名以後，至少可以部分避免發生上述問題的機率。討論是由ben hall的問題引起的，他發現（不從事程式設計的）測試人員群體不像其他社群那麼活躍，對此他覺得很疑惑：
社群裡的測試人員都**去了？開發人員很容易找，從大型會議（pdc、teched）到小型使用者組（nxtgenug），類似的活動很多。兩年前，nxtgenug在考文垂舉辦首次活動，從那時起我就是它的成員了；而且我還參加teched europe會議。但是在這些活動中為什麼見不到測試人員？還是我眼拙沒注意到？很有意思，對ben的問題的最初回應是這麼說的：「是有這樣的社群的，但是他們比較孤立，很大一部分原因是為了避免由於用詞混淆帶來的溝通誤解」。由此激起了大家更熱烈的反響，討論使用新詞彙所能帶來的好處，比如用「微測試」表示tdd中程式設計師使用的「單元測試」方式。我知道公司的招聘人員們一直對此問題感到疑惑，但是從社群的角度來看——測試人員都去哪兒了？他們的交流在**進行？如何改進軟體測試、測試人員如何融入到專案結構中、測試人員如何利用最新的開發技術？類似的問題一定會有人關心的，但是這些人在**？
hill帶頭，強調了他使用「微測試」所帶來的正向產出，新的xp團隊因此理解了單元測試的著眼點是放在極其細微的測試「單元」之上，而不是傳統的非xp開發過程中所著眼的、較大範圍的「單元」。mike不只強調了這個區別，他還指出了tdd和微測試的真實意圖及其與傳統測試意圖的差異。
我們發現：密集的微測試驅動開發帶來的好處不僅僅是提高質量。質量的提公升是tdd的乙個***。實際上，我們所傳授的tdd的好處和真正意圖，是要指導生產力：更多功能，更快發布。很多帖子都對mike的主意表示贊同。其中，xp大牛ron jeffries說道：
我非常同意這才是tdd真正的好處，我也很仰慕你［如此自信］敢於直接把它講出來。此外，這個討論的有趣和有用之處在於引發的眾多不同觀點和例項，展示了引入「微測試」這樣的詞彙所帶來的優劣之處，比如乙個內容充實的列表，列出了真正的微測試的特徵。
要想檢視完整內容，您可以點選該鏈結，並可以讓讀者知道您對這個問題怎麼看。
寫單元測試，我不認為是件容易的事
這是乙個40多歲還在編碼的老程式設計師對單元測試的理解和實踐。裡面沒有廢話，希望每句話能說到你心坎裡。自己的含義 方法邊界內的主體邏輯。一切下游方法 框架依賴 外部io等都不是自己。如spring 外部資料庫都視為外部邏輯。每個方法有自己獨立的單元測試，這有利於ide在單元測試與邏輯 間跳躍，便於定...
我的單元測試認識之路 下
進入新公司之後，開發方式跟以前相比變化很大。以前公司做的專案基本上沒有什麼文件，只有一系列的使用者需求，然後根據需求來決定該怎麼做，做成怎麼樣。但 在這裡，動手之前首先需要準備user story，即虛擬出終端使用者的操作，寫成文件來決定我們應該如何做，怎麼去做。最初，我是根據user story的...
我的單元測試認識之路 上
本文並不是告訴你如何使用nunit進行單元測試，關於你如何進行單元測試的文章已經有很多。我這裡只是說說我接觸單元測試這一年半的時間自己所領悟到的一些東西，當然這只是我個人的心得，估計裡面也會有錯誤，期待各位高手來對不對的地方進行指正。初次接觸單元測試是一年半以前參加乙個工作流引擎的開發。那時我剛畢業...