在信息技術中，單元測試是檢驗代碼原子構成的實踐，越小的原子構成，越好的進行檢測。OOP中的一個單元，通常指一個類至少需要一個測試檢查每個類的公共方法。然而，在實踐中什么是一個測試？一個測試是一個單獨的函數，執行一個單獨的動作并檢查執行的動作提供期待的結果。如果結果正確，測試通過；否則測試失敗。通過單元測試，開發者的工作會更輕松，因為當一個 bug 并非自愿的在不斷改動中被添加到代碼，很可能一個已經編寫的測試會失敗可以指出一定精確程度的出錯位置。當代碼需要廣泛的測試時（一個代碼覆蓋率的概念），可以進行這項工作。當遇到一個錯誤，并且沒有測試失敗，最好是編寫一個新的測試準確的重現相同的錯誤。通過這個方式，會很容易檢查，以使在隨后的改動中這個故障不會再次偶然出現。 許多開發者認為單元測試浪費時間。可能因為他們沒有考慮一個良好的測試基礎會對他們的項目有多么積極的影響。有一個好的代碼覆蓋率意味著代碼的改動可以更有信心，因為如果一些危險的東西被觸及，測試會失敗幫助你解決這個問題。另一個測試的好處是他們為想要使用這個經過測試的庫的開發者提供了真實的例子；測試中的代碼非常易讀，因為它是為了自身的性質，并提供了一種在線的文檔。一個積極的作用是，一個曾經編寫測試的開發者更關注編寫具有較少的依賴性的代碼，而且更獨立于上下文環境：因為測試依賴過多的類的確很痛苦。 單元測試的概念并沒有明確的結合到一個技術實現，而且潛在地一個單元測試也可以是一組手寫在一張紙條上的說明；使測試真正有效的是，當他們被集中在一個自動化的背景中。 測試聚集于一個處理單元，一次性執行它們所有的測試，報告測試運行的數量，并報告測試失敗的適量和它們的名字。自動處理被重復多次，在開發中可以幫助定位 bug ， 這也是為什么測試經常用來優化性能。開發者往往在它們執行的太慢或者使他們工作太辛苦時放棄測試。 單獨的測試也在執行的上下文中，每個測試必須獨立于其它的，必須不依賴于某個特定的配置。如果測試互相連接，一個錯誤可能破壞整個測試鏈，使得 bug 更加難以發現。環境不應該影響測試，因為這是危險的，測試可能被移走，應用到另外一個機器上，所以應該有最小的配置依賴。 有些地方不是那么容易適合單元測試，通常 UI 和數據庫。因為第一種情況，用戶交互界面是必須的，往往會丟掉自動化處理的好處。數據庫難以測試基于各種事實：他們必須被配置，表結構必須存在，測試數據必須以某種方式持續的生成和刪除，并且當同樣的測試重復時有相同的狀態。開發者社區提供許多策略處理這些問題，在更深的層次介紹單元測試技術，這超出了本書的范圍。