單元測試框架的選擇

2022-08-17 23:21:16 字數 1302 閱讀 4466

今天給大家介紹單元測試的概念,以python語言為基礎,帶你了解如何選擇單元測試框架。

單元測試是指,對軟體中的最小可測試單元在與程式其他部分相隔離的情況下進行檢查和驗證的工作,這裡的最小可測試單元通常是指函式或者類。

從「基礎元件」開測,單元測試物件是**,以函式或類為單位,完成基礎測試,在**封裝成「功能」後,更容易定位功能上出現的問題

通常來講,單元測試的用例是乙個「輸入資料」和「預計輸出」的集合。 你需要針對確定的輸入,根據邏輯功能推算出預期正確的輸出,並且以執行被測試**的方式進行驗證,用一句話概括就是「在明確了**需要實現的邏輯功能的基礎上,什麼輸入,應該產生什麼輸出」。

驅動**、樁**、mock**

驅動**(driver)指呼叫被測函式的**,在單元測試過程中,驅動模組通常包括呼叫被測函式前的資料準備、呼叫被測函式以及驗證相關結果三個步驟。驅動**的結構,通常由單元測試的框架決定。

樁**(stub)是用來代替真實**的臨時**。 比如,某個函式a的內部實現中呼叫了乙個尚未實現的函式b,為了對函式a的邏輯進行測試,那麼就需要模擬乙個函式b,這個模擬的函式b的實現就是所謂的樁**。樁**的應用首先起到了隔離和補齊的作用,使被測**能夠獨立編譯、鏈結,並獨立執行。同時,樁**還具有控制被測函式執行路徑的作用。

mock**和樁**非常類似,都是用來代替真實**的臨時**,起到隔離和補齊的作用。但是很多人,甚至是具有多年單元測試經驗的開發工程師,也很難說清這二者的區別。

在作者看來,mock**和樁**的本質區別是:測試期待結果的驗證(assert and expectiation)。

對於mock**來說,我們的關注點是mock方法有沒有被呼叫,以什麼樣的引數被呼叫,被呼叫的次數,以及多個mock函式的先後呼叫順序。所以,在使用mock**的測試中,對於結果的驗證(也就是assert),通常出現在mock函式中。

對於樁**來說,我們的關注點是利用stub來控制被測函式的執行路徑,不會去關注stub是否被呼叫以及怎麼樣被呼叫。所以,你在使用stub的測試中,對於結果的驗證(也就是assert),通常出現在驅動**中。

在python中,我們常用的單元測試框架是unittest、pytest,相比之下pytest更具有學習價值,原因是pytest**更簡潔。而且pytest框架結合selenium做ui自動化也比較方便。

可能單元測試大家做的不是很多,因為單元測試基本都是開發的同事在做,但是這並不妨礙大家學習pytest框架。

go Test 單元測試 測試框架

1.建立乙個名為 test.go 的檔案 如果是包中的單元測試,就在包所在目錄下建立該檔案 並將下面的 新增到其中,函式命名統一為test t testing.t package main 包中的單元測試main替換成包名 import testing func testsum t testing....

Qt單元測試框架

qtestlib 框架提供了乙個簡單易用的單元測試框架,需要在工程檔案中新增qt testlib。先看乙個簡單的例子 此外,qt還提供了以下四個會被自動呼叫的private slot inittestcase 在測試開始前被呼叫 cleanuptestcase 在測試結束後被呼叫 init 每個測試...

Test Unit Ruby單元測試框架

test unit ruby單元測試框架 介紹 單元測試是xp的核心部分。xp是偉大的,單元測試已出現了很長一段時間,而且它是乙個很好的思想。好的單元測試的關鍵部分不是寫測試 而是要測試。兩者有什麼不同嗎?當然,如果你只是寫測試 而不用它,那麼你以後對 的修改將不會得到保證。換句話說,如果你已經測試...