Home >> Blog >> 什麼是 unit test 單元測試？
什麼是 unit test 單元測試？
單元測試是一種測試單元的方法——可以在系統中邏輯隔離的最小程式碼段。在大多數編程語言中，它是函數、子例程、方法或屬性。定義的孤立部分很重要。作者 Michael Feathers 在他的《有效地使用遺留程式碼》一書中指出，當這些測試依賴於外部系統時，它們就不是單元測試：“如果它與數據庫對話，它通過網絡對話，它接觸文件系統，它需要係統配置，否則不能與任何其他測試同時運行。”
現代版本的單元測試可以在 JUnit 等框架或TestComplete等測試工具中找到。再看一點，您會發現 SUnit，它是由 Kent Beck 創建的所有單元測試框架之母，並且是軟件測試藝術第 5 章中的參考資料。在此之前，這主要是一個謎。我向 Jerry Weinberg 詢問了他在單元測試方面的經驗——“我們在 1956 年進行了單元測試。據我所知，只要有計算機，它就一直在進行”。
不管單元測試何時何地開始，有一件事是肯定的。單元測試將繼續存在。 讓我們看看單元測試的一些更實際的方面。
單元測試是什麼樣的？
一個單元幾乎可以是您想要的任何東西——一行程式碼、一個方法或一個類。不過一般來說，越小越好。較小的測試可以讓您更詳細地了解程式碼的執行情況。還有一個實際的方面是，當您測試非常小的單元時，您的測試可以快速運行；就像在一秒鐘內快速進行一千次測試。
考慮這個示例程式碼：
def 分隔符 (a, b)
返回 a/b
結尾
使用 Ruby，這些小測試可能看起來像這樣：
類 smallTest < MiniTest::Unit::testCase
def tiny_test
@a=9
@b=3
assert_equal（3，除法器（a，b））
結尾
結尾
這個例子過於簡單，但它讓你明白我所說的小是什麼意思。小型測試還具有使跨系統變得更加困難的好處——從程式碼到數據庫或第 3 方系統。嚴格來說，跨系統並沒有什麼問題，但是會產生諸如逐漸減慢測試的後果。幾年前，我在一家公司工作，它悄悄進入了測試集，最終我們進行了數千次測試，為數據庫設置和拆除腳本，還有一個需要數小時才能運行的測試套件。
那麼誰應該創建單元測試呢？
Robert V. Head 在他的《實時業務系統》一書中說：“通常，單元測試被認為是編程階段的一部分，編寫程序的人……單元測試”。這並不是因為程式設計師掌握了單元測試的秘訣，而是因為它是有意義的。編寫 prod 程式碼的程式設計師可能知道如何訪問可以輕鬆測試的部分，以及如何模擬無法訪問的對象。這是一個時間權衡。
其他時候，有人會在事後介入並編寫測試以幫助創建安全防護，同時重構或進一步開發程式碼庫的該區域。
我能用它們做什麼？
錘子是很棒的工具，可以幫助您完成許多不同的工作——打開車窗或關閉鬧鐘。但是，特別適合將釘子穿過堅硬的表面。單元測試類似。他們可以做很多不同的事情，他們可能應該只做一些。
測試驅動開發
測試驅動開發（TDD）是一種程式碼設計技術，程式設計師在任何生產程式碼之前編寫測試，然後編寫使該測試通過的程式碼。這個想法是，從最初的測試中得到一點保證，程式設計師可以隨意重構和重構更多，以獲得他們知道如何編寫的最乾淨的程式碼。這個想法很簡單，但就像大多數簡單的事情一樣，執行起來很困難。TDD 需要一種與大多數人所習慣的完全不同的思維方式，以及處理最初可能會減慢您速度的學習曲線的韌性。
檢查你的工作
TDD 並不是什麼新鮮事物，但在這一點上，它仍然主要是為 go getter 服務的。我們其他人正在檢查我們的工作。在編寫生產程式碼後編寫單元測試可能是一種更傳統的方式，但同樣有用。如果您在過去十年中的任何時候上過數學課，這也是您熟悉的東西。
在檢查您的工作並且很明顯程式碼正在執行您認為它正在執行的操作之後，單元測試的值會發生一些變化。可以在產品的每個構建中輕鬆運行的測試充當更改檢測，當程式碼以意外方式更改時通知您。
程式碼文檔
程式碼文檔是一種拖累，它主要表現在編寫程式碼文檔的程度。單元測試可以通過鼓勵更好的編碼實踐和留下描述你的產品正在做什麼的程式碼片段來減輕文檔負擔。您不必不斷地向文檔猛獸提供程式碼更改，而是更新一個適合您的檢查系統。
危險區
如果可能，您將希望避免使用單元測試的一些用途。可以創建跨系統邊界和接觸數據庫或第 3 方系統的集成測試，但這很快會導致測試套件隨著每個添加的測試運行的時間越來越長。有很多專門用於更高級別測試的測試框架。如果您想一次測試較大的產品部分，您可能需要研究那些其他框架。
另一個風險領域是端到端測試。這些通常需要仔細排序，依賴於其他測試，並仔細設置以使您的系統處於特殊的“測試就緒”狀態。就像集成測試一樣，有很多工具可供選擇。
你絕對可以用單元框架來做這些事情，但它可能很快就會變得比它的價值更多。
常見問題：
我們在單元測試中遇到的最常見問題通常不是技術問題。
在單元測試相當於加載最新版本並查看它是否啟動的環境中花費時間之後，人們很難適應新的工作方式。測試感染群體是一種文化現象。通過找到一個有興趣並投資於保持最新狀態的人，我在改變測試方式方面取得了最大的成功。這個人可以成為你的擁護者，幫助建立單元測試有用性的案例，並通過她的成功幫助在開發組織中傳播這個想法。(http://dilbert.com/strip/2011-03-24)
還有一個神話說，如果測試好，那麼測試越多越好。智能測試很好，將有助於創建有價值的、穩定的產品。但智能測試並不總是以令人印象深刻的測試數量結束。智能單元測試快速且頻繁地提供有關您的軟件的相關資訊。
我們已經介紹了單元測試的一些基礎知識，並為您提供了一些與您的團隊討論它們的方法。
下一步是開始您自己的，最好是小型的測試。