在第一篇文章中(使用mockito寫測試用例(一)),介紹了使用mock寫一些的測試類。但是對於一些複雜的測試類,使用mockito還是有些困難的。但是為了覆蓋率,某些類的某些方法又必須測試得到,這就是個問題。
①、mock的測試類無法呼叫靜態方法(使用powermock解決)
②、如果想要mock多個層級的類,就比較複雜了。
如果私有方法中有呼叫其他層的方法,又需要mock,測試通過反射呼叫時就需要注意一些細節。
如下**所示:
@service
public class userserviceimpl implements userservice
private string queryuserbyother(string test)
}//測試:
@runwith(springrunner.class)
@springboottest
@before
public void setup()
@injectmocks
userserviceimpl userserviceimpl = new userserviceimpl();
@mock
private userdao userdao = new userdaoimpl();
@test
public void testprivate() catch (exception e)
}
注意:這有乙個坑,在method的invoke方法中,如果不使用userserviceimpl,而使用的是aclass.newinstance(),則會出現npe。原因是:我已經將userserviceimpl這個例項設定為被測試的目標類,而通過mock的dao物件就會注入到該例項中。所有如果使用其他例項(aclass.newinstance()),肯定沒有注入dao物件,當然無法呼叫dao的方法。
//service層
@service
public class userserviceimpl implements userservice
@override
public string queryuserbyid(string id) }
//dao層
@data
@service
public class userdaoimpl implements userdao
}//測試用例
@runwith(springrunner.class)
@springboottest
@before
public void setup()
@injectmocks
userservice userservice = new userserviceimpl();
@spy
private userdaoimpl userdao = new userdaoimpl();
@mock
private userdatabase userdatabase;
@test
public void test5()
}
測試結果:
總結1)、個人認為關鍵點是:將dao層的依賴介面(userdatabase )mock時,通過set注入到userdao中。如果不寫這行**,則預設將userdatabase 注入到userservice中,所以後續執行時肯定會出現npe。一般情況,我們使用verify、doreturn足以完成測試,但是有時候面對一些複雜的業務邏輯,就顯得力不從心了。doanswer可以用來判斷執行的方法和方法的入參,並做一些處理等等,有一箭雙鵰的作用(doanswer和thenanswer作用一樣的)。如下所示2)、理論上可以解決多層呼叫的問題,但是需要mock、spy大量的資料,但是這就有一點違背初心了。畢竟使用mock寫測試用例的目的就是:只需要關注被測試的業務**即可,其他的mock掉。如果都測試,還不如直接聯調簡單粗暴。
方式一:
方式二:
在寫測試用例時,我們需要驗證業務邏輯是否正確,即不僅測試成功的情景還要測試失敗的場景。一句話:所有的場景都要覆蓋到。在含有try-catch的邏輯部分,測試catch部分時就用到了thenthrow。如下**所示:
//mock業務邏輯
@override
public string queryuserbyname(string name) catch (exception e)
return daouserbyname;
}/**
* 測試用例:
* thenthrow的使用
* 引數:必須指定乙個異常。
*/@test
public void test1()
執行結果:
測試用例怎麼寫?
測試用例 為了特定的目的 證明軟體存在某問題 而設計的一組由測試輸入 執行條件 預期結果構成的文件 要做這個登入頁面的測試用例,你會從哪些方面思考進行測試呢?看似簡單的頁面功能能夠設計多少條測試用例完成較全面的測試呢?10條以內?20條?測試用例簡單來說就是指導如何做測試的文件,該文件主要記錄需要驗...
如何寫測試用例
1 了解軟體的原始需求 測試目的 在編寫乙個軟體或者模組的測試用例時候,一定要明白這個功能的原始需求,也就是軟體的使用者 客戶 的需求。理解原始需求後,編寫的測試用例才更有目的性。2 熟悉軟體的功能需求 測試點 這個功能需求是指軟體的細化需求點,這個一般在需求文件裡面都會體現。這裡要做的是把需求穩定...
如何寫介面測試用例(並篩選冒煙測試用例)
關於介面測試用例的等級劃分 1 主體業務功能介面正常典型值用例的優先順序為1 用於冒煙測試的用例 2 各模組主功能的正常典型值用例的優先順序為2 3 除了的正常典型值用例之外的正用例及所有異常用例的優先順序為3 4 可用性測試以及入參預設值以及開發做了限制處理的引數型別 開發自測容易發現的錯誤等測試...