首頁猿問如何模擬調(diào)用同一類中存在的其他方法的方法

如何模擬調(diào)用同一類中存在的其他方法的方法

Java

慕尼黑8549860 2023-04-26 14:49:07

我是 Mockito 的新手。我正在使用 Mockito 為一個類編寫測試。我有一個調(diào)用同一類的其他方法的方法。我將如何嘲笑這種方法？我已經(jīng)發(fā)布了我試圖為其編寫測試的課程。我正在嘗試模擬方法 process(PersonDTO person)public class Processor { @Autowired private SomeService service; @Autowired private SomeServiceProperties properties; private Util util = new Util(); public SPMOutboundVO process(PersonDTO person) throws Exception { SPMOutboundVO outboundVO = null; if(validatePersonForBenefitsProcessing(person)) { PersonPayrollFromWorkdayVO personPayrollFromWorkdayVO = service.getPersonPayrollFromWorkday(util.getStartOrEndDate(DayOfWeek.SUNDAY),util.getStartOrEndDate(DayOfWeek.SATURDAY),person.getEmployeeID()); if(personPayrollFromWorkdayVO != null) { person.setBillingStartDate(getPayrollPeriod(personPayrollFromWorkdayVO)); person.setAmount(util.getMonthlyDiscountPayRate(person.getPayPeriod(),getDiscountRate(personPayrollFromWorkdayVO))); } if(isNewLeave(person,getPayrollPeriod(personPayrollFromWorkdayVO))) { person.setBillingStartDate(getPayrollPeriod(personPayrollFromWorkdayVO)); outboundVO = processOutboundSPMInsertRecords(person); } else if (person.isReturnFromLeaveOrTermed()){ person.setBillingEndDate(person.getFirstDayBackAtWorkMinus1()); outboundVO = processOutboundSPMUpdateRecords(person); } } return outboundVO; } public boolean validatePersonForBenefitsProcessing(PersonDTO person) { // Some code } public SPMOutboundVO processOutboundSPMInsertRecords(PersonDTO person) { // Some code } public SPMOutboundVO processOutboundSPMUpdateRecords(PersonDTO person) { // Some code } public String getPayrollPeriod(PersonPayrollFromWorkdayVO personPayrollFromWorkdayVO) { // Some code } public boolean isNewLeave(PersonDTO, String) { // Some code }}

查看完整描述

1 回答

FFIVE

TA貢獻(xiàn)1797條經(jīng)驗獲得超6個贊

首先，從技術(shù)上講，您可以使用 mockito 從類中模擬選定的方法。此功能稱為部分模擬。

第二：在某些情況下，在測試一個類以模擬來自同一類的其他方法時是有意義的。一個很好的例子是將與其他組件的交互捆綁在一起的方法（為了舉例起見，我們稱它為do_interactions），這樣該類的其余方法就沒有此類交互，并且僅為do_interactions該目的調(diào)用。更具體地說，考慮一種為其他方法傳遞文件內(nèi)容的方法：它將與操作系統(tǒng)的交互（如打開和閱讀）捆綁在一起，并只返回內(nèi)容。然后，您可以通過模擬該函數(shù)使其在測試需要時返回“模擬”文件內(nèi)容，從而輕松地執(zhí)行與操作系統(tǒng)隔離的測試。

也就是說，有些例子表明這種嘲笑是有道理的，但這不一定適用于您的情況。

第三，測試是關(guān)于發(fā)現(xiàn)錯誤（參見 Myers、Badgett、Sandler：軟件測試的藝術(shù)，或 Beizer：軟件測試技術(shù)等），單元測試旨在發(fā)現(xiàn)那些可以在孤立代碼中找到的錯誤.?為了有效地發(fā)現(xiàn)錯誤，您必須進(jìn)行特定于實現(xiàn)的測試：錯誤在實現(xiàn)中，不同的實現(xiàn)有不同的錯誤。想一想大量的排序算法：它們都有相同的 API，但它們的實現(xiàn)卻完全不同。或者，考慮實現(xiàn) Fibonacci 函數(shù)的方法：作為迭代或遞歸函數(shù)，作為封閉形式的表達(dá)式 (Moivre/Binet)，或作為查找表。同樣，界面始終相同，可能的錯誤差異很大，單元測試策略也是如此。和，單元測試是最接近實現(xiàn)級別的測試級別——集成測試、子系統(tǒng)測試和系統(tǒng)測試都在上升，因此不太適合在實現(xiàn)中查找錯誤。因此，嘗試在單元測試中保持與實現(xiàn)無關(guān)可能會導(dǎo)致測試套件效率降低。

也就是說，您確實也應(yīng)該努力降低測試維護(hù)工作量。這意味著，如果特定測試不需要特定的測試用例實現(xiàn)，則不要將其具體化。并且，對于那些有充分理由是特定于實現(xiàn)的測試，仍然盡量保持較低的維護(hù)工作量，例如通過在輔助方法中提取測試的特定于實現(xiàn)的部分，以減少您必須維護(hù)的測試代碼量，以防萬一SUT 的更改。

反對回復(fù) 2023-04-26