1 回答

TA貢獻1797條經驗 獲得超6個贊
首先,從技術上講,您可以使用 mockito 從類中模擬選定的方法。此功能稱為部分模擬。
第二:在某些情況下,在測試一個類以模擬來自同一類的其他方法時是有意義的。一個很好的例子是將與其他組件的交互捆綁在一起的方法(為了舉例起見,我們稱它為do_interactions
),這樣該類的其余方法就沒有此類交互,并且僅為do_interactions
該目的調用。更具體地說,考慮一種為其他方法傳遞文件內容的方法:它將與操作系統的交互(如打開和閱讀)捆綁在一起,并只返回內容。然后,您可以通過模擬該函數使其在測試需要時返回“模擬”文件內容,從而輕松地執行與操作系統隔離的測試。
也就是說,有些例子表明這種嘲笑是有道理的,但這不一定適用于您的情況。
第三,測試是關于發現錯誤(參見 Myers、Badgett、Sandler:軟件測試的藝術,或 Beizer:軟件測試技術等),單元測試旨在發現那些可以在孤立代碼中找到的錯誤.?為了有效地發現錯誤,您必須進行特定于實現的測試:錯誤在實現中,不同的實現有不同的錯誤。想一想大量的排序算法:它們都有相同的 API,但它們的實現卻完全不同。或者,考慮實現 Fibonacci 函數的方法:作為迭代或遞歸函數,作為封閉形式的表達式 (Moivre/Binet),或作為查找表。同樣,界面始終相同,可能的錯誤差異很大,單元測試策略也是如此。和,單元測試是最接近實現級別的測試級別——集成測試、子系統測試和系統測試都在上升,因此不太適合在實現中查找錯誤。因此,嘗試在單元測試中保持與實現無關可能會導致測試套件效率降低。
也就是說,您確實也應該努力降低測試維護工作量。這意味著,如果特定測試不需要特定的測試用例實現,則不要將其具體化。并且,對于那些有充分理由是特定于實現的測試,仍然盡量保持較低的維護工作量,例如通過在輔助方法中提取測試的特定于實現的部分,以減少您必須維護的測試代碼量,以防萬一SUT 的更改。
添加回答
舉報