3 回答

TA貢獻(xiàn)1834條經(jīng)驗(yàn) 獲得超8個(gè)贊
這是因?yàn)閭鬟f給 Calc.divide 的值仍然相同。Mockito 驗(yàn)證傳遞的值而不是參數(shù)的名稱(chēng)。因此更改 Calc 類(lèi)中參數(shù)的順序不會(huì)影響測(cè)試,除非您更改方法 serviceAMethod 中完成的調(diào)用以反映更改。
public void serviceAMethod() {
//do somehting
a=getA();
b=getB();
calc.divide(b,a);
}
只有在您更改此邏輯(這是您正在測(cè)試的)之后,您的測(cè)試才會(huì)失敗。
如果您使用實(shí)際值,您可以看到這一點(diǎn):
public void serviceAMethod() {
a=getA(); // EG: 1
b=getB(); // EG: 2
calc.divide(1, 2); // effective call
}
如果您在 Calc 類(lèi)中交換 a 和 b,它仍將使用值 1、2 調(diào)用。然后您測(cè)試以下內(nèi)容:
verify(calcMock).divide(1, 2);

TA貢獻(xiàn)1859條經(jīng)驗(yàn) 獲得超6個(gè)贊
好的,這是我的解決方案,我認(rèn)為它比完整的集成測(cè)試更好
我已將參數(shù)重構(gòu)為 pojo
public class OperationRequest {
private int firstOperand;
private int secondOperand;
//equals and hashCode, important!
}
然后 Calc.divide 變成
calc.divide(OperationRequest request);
和斷言
verify(calcMock).divide(new OperationRequest(1,2));
如果您交換操作數(shù),這將失敗

TA貢獻(xiàn)1853條經(jīng)驗(yàn) 獲得超18個(gè)贊
對(duì) serviceAMethod 的測(cè)試是在假設(shè)簽名的情況下編寫(xiě)的,divide
即第一個(gè)參數(shù)是被除數(shù),第二個(gè)參數(shù)是除數(shù)。
現(xiàn)在 的簽名divide
發(fā)生了變化,即第一個(gè)參數(shù)現(xiàn)在是一個(gè)除數(shù),第二個(gè)參數(shù)是一個(gè)被除數(shù)。但是測(cè)試serviceAMethod
還是通過(guò)了。
calc 的單元測(cè)試肯定會(huì)捕捉到這一點(diǎn),但是如果divide
在這種情況下對(duì)每個(gè)客戶(hù)端的某些測(cè)試也失敗了,這會(huì)很方便,因?yàn)檫@種簽名的更改divide
肯定會(huì)破壞客戶(hù)端并需要更改客戶(hù)端。
當(dāng)您更改方法解釋其參數(shù)的方式時(shí),這肯定需要更改方法的客戶(hù)端。模擬測(cè)試divide
無(wú)法檢測(cè)到這種變化。
serviceAMethod
使用 real的集成測(cè)試Calc
會(huì)檢測(cè)到這種變化并且會(huì)中斷。這會(huì)給你一個(gè)提醒,serviceAMethod
應(yīng)該改變它以其他順序傳遞參數(shù)。
添加回答
舉報(bào)