單元測試ppt

時間 2019-11-20

原文原文鏈接

單元測試ppt思路詳解

目前的情況：
1，如今不少單元測試只是利用@Test註解把代碼或者整個請求接口內的business作測試
2，單測的過程就不少查數據庫的方法，可是不必每次都測sql，由於sql測一遍都應該是正確的。
3，單測代碼啓動速度、效率過低
4，沒有在各個環境整個工程單元測試經過
5，未採用assert機制，採用system.out.println進行人工覈查輸出狀況
6，關閉了jenkins上單元測試流程
7，時間緊，開發經過swagger頁面和端點調試進行代碼功能的驗證工做

目標改進：
1，單元測試啓動效率提高
2，脫離環境，在每一個環境都放心執行
3，提供代碼覆蓋率
4，用於改善和提升開發效率、編碼質量、編碼可讀性、減小冗長的代碼行
測試金字塔：
web

AIR 原則：

Automatic(自動化)：單元測試應該是全自動執行的，而且非交互式的。

Independent(獨立性)：保持單元測試的獨立性。爲了保證單元測試穩定可靠且便於維護

Repeatable(可重複)：單元測試是能夠重複執行的，不能受到外界環境的影響。

老闆爲我有效的代碼支付薪酬，而不是測試，因此個人理念是在能達到的自信水平上作越少的測試越好（我以爲這種自信水平應該要高於行業內的標準，固然這也可能只是個人自大）。我對編碼過程當中一般都不會犯的一類錯誤（好比在構造方法中錯誤地賦值）不會進行測試，而更傾向於對那些有意義的錯誤進行測試，因此對於一些具備業務邏輯的複雜條件我會特別當心。當在一個團隊中合做時，我會很是當心地修改個人策略，以便測試那些容易讓團隊出現錯誤的地方。

如何作：
1，必須基於團隊正式的代碼工程，而不是隨便找一個示例代碼工程來說解——這樣的書和文章已經太多了，我不會比他們作的更好；

2，必須識別並提取出小的可測試單元，但不要讓團隊成員學習更多的高深的知識，好比設計模式、Mock&Stub等；

3，最好可以度量，好比能提升10% - 20% 的測試覆蓋率。redis

單元測試的編寫，主要包含如下幾個階段：

spring

數據準備：在編寫測試用例前，須要依賴到一些數據，數據來源通常是數據庫。sql
構造參數及打樁（stub）：調用方法須要傳遞入參，依賴的類須要作mock和stub數據庫
執行測試：這一步比較簡單，直接調用被測方法便可。設計模式
結果驗證：這裏除了驗證被測方法的返回值外，還須要驗證插入到數據庫中的數據是否正確，某外部方法被調用過n次或未調用過。mybatis
必要的清理：對打樁進行清理，對數據庫髒數據進行清理。

mvc

mockio使用基礎，主要是兩個註解的認識，而後其它語法請本身參照

@mock Mock聲明的對象，對函數的調用均執行mock（即虛假函數），不執行真正部分。
@spy Spy聲明的對象，對函數的調用均執行真正部分。
@InjectMocks 通常來修飾你須要測試的頂層類。使用這個註解能夠建立一個實例，而且將你用@Mock註解的對象注入到這個實例中。

@spy +@Autowired 這個對象的依賴的類也是會自動autowired，若是個人依賴的對象還有依賴（這在大多數的項目中是很是常見的），根據上面的說法用@Spy的對象是不會自動注入依賴的
@InjectMocks+@Autowired 兩個註解疊加使用，讓@Autowired註解爲對象注入真依賴。

app

when和doReturn

when(dao.getOrder()).thenReturn("returened by mock ");框架

doReturn(expected).when(underTest).methodToTest();

使用when去設置模擬返回值時，它裏面的方法（dao.getOrder()）會先執行一次。

使用doReturn去設置的話，就不會產生上面的問題，由於有when來進行控制要模擬的方法，因此不會執行原來的方法。

分層的測試：
給一個目前的圖例：controller-》service-》dao層的測試

提供mybatis層，service層，controller的測試

數據庫有dbunit，spring 的@sql註解來實現數據載入

service層的測試：

controller層的測試如何測。

@RunWith(SpringRunner.class) : SpringRunner是SpringJUnit4ClassRunner的簡寫，它擴展了BlockJUnit4ClassRunner類，用於提供測試時的Spring應用上下文信息。
@WebMvcTest(value=UserController.class,secure = false) : 該註解用於測試Spring MVC應用程序，使用此註解的好處是咱們只須要加載UserController類並對其中的方法進行單元測試，而不須要加載其餘的控制器。
@MockBean : MockBean主要是模擬向Spring應用上下文注入一個Bean對象，並使該Bean對象能夠在控制器中被訪問到。
MockMvc : MockMvc是測試Spring MVC應用程序的主要入口，它將爲咱們的測試提供一個模擬的應用上下文環境。

普通的按照service的測試模式能夠嗎?丟失了什麼東西：
須要springmockmvc來測試：
mockcontroller層依賴的service和utils類的方法

如何measuser測試覆蓋率：
IDEA如何測試代碼的覆蓋率統計

一些tips：
1，若是寫了一些實際調用其它系統的單元測試，可是在跑jenkins單元測試依賴環境不能部署怎麼辦。添加igonore註解
2，@PrepareForTest(HelloUtil.class)
一些問題：
1，在開啓單元測試後，每次部署慢的狀況如何解決（目前只包含打包，上傳和部署都有7分鐘的gap時間了，如何改進）
2，要作好單元測試，首要條件是要有單元。若是組件內的代碼沒有分紅清晰獨立的小單元，那單元測試就無從談起。因此，三分測試，七分設計。
若是能將代碼合理地拆分紅不一樣的單元，你就會發現，大部分單元，如圖中綠色部分所示，都是很是獨立的，它們不依賴數據庫等外部資源，只是一個內存的計算，因此這部分是很是容易作自動化單元測試的。
因此，當你的應用的自動化單測覆蓋率只是個位數的話，先不要急着引入MOCK框架這類工具，當務之急是作這種單元化的改造，測試那些投入產出效果明顯的部分。之後在用MOCK等方式測試其它的部分。

在介紹這些單元測試的方法後，你們能不能總結一下單元測試應該具體什麼特性：