通過集成測試引發理智的多重斷言

我遇到了很多在單元測試期間使用/不使用多重斷言的資源。但是，在編寫UI級別的自動化集成測試時，我最終在一次測試中做了很多斷言，這對我來說似乎不是什麼壞主意，尤其是當我使用軟斷言時，只會在拆解期間失敗並報告測試方法中的所有斷言失敗而不是將其限制爲每個測試一個報告。通過集成測試引發理智的多重斷言

一個這樣的場景是填寫一個有10個字段（文本框，下拉等）的表單。回到表格並驗證所有輸入的值是可用的。我不喜歡我的測試，它充滿了許多斷言。我想斷言所有這些值，但仍然希望我的測試，看起來很乾淨，不喜歡 -

public void testMethod() { 
    // Some operation here 
    softAssert("verification failed for field 1, expected value:" +value, isValuePresent(value)); 
    softAssert("verification failed for field 2, expected value:" +value, isValuePresent(value)); 
    softAssert("verification failed for field 3, expected value:" +value, isValuePresent(value)); 
    // Some more assertions here 
}

我可以提取這些斷言，以不同的方法，但後來我覺得斷言應保存在試驗方法。明確測試方法中正在測試的內容。

只是一個微不足道的感覺，我有這樣的測試設計是合理的嗎？或者我可以在我的測試方法中進行設計增強。

來源

2011-12-01 Tarun

你可以做我所謂的「通過實例斷言」，這只是表單級別的斷言。它看起來像這樣：

public void testMethod() { 
    Form expected = new Form() 
        .field1('value1') 
        .field2('value2') 
        .field3('value3') 
        .field4('value4') 

    Form result = someFormOperation(); 

    softAssert(expected, result); 

}

來源

2011-12-01 05:58:28

我經常在某些結果和assertEquals上調用toString（）來獲得正確的結果。如果你的底層對象實現了合理的toString（或者toXML等），那簡化了測試代碼。但對未來的變化不太健壯。

來源

2011-12-01 06:28:36 user949300

我認爲它實際上會更好地打破未來的變化，所以更可能的是測試會更新。 –

通過集成測試引發理智的多重斷言

回答

相關問題