在下面的示例中，我想測試給定的源，是否構建了正確的 JSON 并將其映射到返回的對象中。起初，代碼在其中創建了新的對象，如下所示：@Overridepublic Map<String, Object> getAttributes( Source source, Response response ){ Objects.requireNonNull( response, "response can not be null" ); final Map<String, Object> attributes = new HashMap<>( ); final JSONArray users = new JSONArray( response.getEntityContentAsString( ) ); final Set<String> mappedUsers = new HashSet<>( ); for ( int i = 0; i < users.length( ); i++ ) { mappedUsers.add( users.getJSONObject( i ).getString( "name" ) ); } attributes.put( "mappedUsers", mappedUsers ); return attributes;}但它有問題，首先，我不想使用 PowerMock 或其他反射實用程序來模擬新對象的創建。但是要測試這段代碼；我必須在response.getEntityContentAsString( )中返回正確的 JSON ，因為我沒有模擬 JSONArray，它應該創建正確的對象。這意味著每次我只想測試此代碼行為時，我都必須修改此“虛擬”json。我必須在對象內添加“名稱”屬性，或者我必須使其長度適合循環。為了防止這種情況，我想介紹工廠內的新對象創建?，F在：@Overridepublic Map<String, Object> getAttributes( Source source, Response response ){ Objects.requireNonNull( response, "response can not be null" ); final Map<String, Object> attributes = new HashMap<>( ); final JSONArray users = jsonArrayFactory.create( response.getEntityContentAsString( ) ); final Set<String> mappedUsers = new HashSet<>( ); for ( int i = 0; i < users.length( ); i++ ) { mappedUsers.add( users.getJSONObject( i ).getString( "name" ) ); } attributes.put( "mappedUsers", mappedUsers ); return attributes;}在我的測試中，我可以模擬它而不是處理與 JSONArray 類一起正常工作的自定義 JSON。此外，我不必處理 JSONArray 的實現，因為我對函數的庫細節不感興趣。但是現在它似乎過度設計了，因為有很多這樣的情況；JSONArray、JSONObject、JSONString等直接在創建的項目中。現在團隊覺得他們必須創建所有這些工廠 JSONArrayFactory、JSONObjectFactory 等。在這個例子中你會做什么？也許我們應該改變我們測試功能的方式？您如何處理新對象的創建并防止第 3 方的實現細節？
1 回答
寶慕林4294392
TA貢獻2021條經驗 獲得超8個贊
它總是一個妥協。
但這種折衷是雙向的：如果你對所有東西都使用工廠，那么是的，你將能夠模擬出幾乎所有東西，并且你不會在測試方法中有任何單一的“新”，但是，你的測試將看起來像一長串模擬，并且很難閱讀/理解/維護測試及其 IMO 測試的強制性要求。
還有一點需要考慮，黑盒測試比白盒測試要好得多。在您的情況下，您不返回JSONArray users，只需將其創建為內部變量即可進行內部計算。
現在，理想情況下，測試應該檢查給定輸入參數列表，該方法是否返回預期值，僅此而已，測試不應該擺弄諸如“如果我想讓它通過，我必須在這里創建內部值”之類的問題以這種特殊的方式，然后創造另一個類似的價值”。這一切都使得測試不明確且非常脆弱。
所以這里有一些“經驗法則”：
總是喜歡黑盒測試。不要檢查方法內部做了什么，最好在編寫測試時甚至不要查看被測類的實現。
始終嘗試編寫在給定參數集的情況下實際返回某些內容的方法 這將使測試更易于閱讀和理解
僅模擬/存根交互 - 該類需要的真正依賴項。通常這些并不多，而且它們出現在非常具體的點上。不要模擬內部變量的創建、就地完成的靜態計算的結果或返回值。
例子：
// mocking example:
class SomeService {
private SomeDAO dao; // this is a real dependency, mock it in test
}
// don't mock
Math.max(a,b)
// don't mock
LocalDateTime.of(...)
// don't mock
public int f() {
...
List<Integer> internalVariable = new ArrayList<>(..)
}
添加回答
舉報
0/150
提交
取消