在下面的示例中，我想測試給定的源，是否構(gòu)建了正確的 JSON 并將其映射到返回的對(duì)象中。起初，代碼在其中創(chuàng)建了新的對(duì)象，如下所示：@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 或其他反射實(shí)用程序來模擬新對(duì)象的創(chuàng)建。但是要測試這段代碼；我必須在response.getEntityContentAsString( )中返回正確的 JSON ，因?yàn)槲覜]有模擬 JSONArray，它應(yīng)該創(chuàng)建正確的對(duì)象。這意味著每次我只想測試此代碼行為時(shí)，我都必須修改此“虛擬”json。我必須在對(duì)象內(nèi)添加“名稱”屬性，或者我必須使其長度適合循環(huán)。為了防止這種情況，我想介紹工廠內(nèi)的新對(duì)象創(chuàng)建?，F(xiàn)在：@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 的實(shí)現(xiàn)，因?yàn)槲覍?duì)函數(shù)的庫細(xì)節(jié)不感興趣。但是現(xiàn)在它似乎過度設(shè)計(jì)了，因?yàn)橛泻芏噙@樣的情況；JSONArray、JSONObject、JSONString等直接在創(chuàng)建的項(xiàng)目中。現(xiàn)在團(tuán)隊(duì)覺得他們必須創(chuàng)建所有這些工廠 JSONArrayFactory、JSONObjectFactory 等。在這個(gè)例子中你會(huì)做什么？也許我們應(yīng)該改變我們測試功能的方式？您如何處理新對(duì)象的創(chuàng)建并防止第 3 方的實(shí)現(xiàn)細(xì)節(jié)？
1 回答
寶慕林4294392
TA貢獻(xiàn)2021條經(jīng)驗(yàn) 獲得超8個(gè)贊
它總是一個(gè)妥協(xié)。
但這種折衷是雙向的：如果你對(duì)所有東西都使用工廠，那么是的，你將能夠模擬出幾乎所有東西，并且你不會(huì)在測試方法中有任何單一的“新”，但是，你的測試將看起來像一長串模擬，并且很難閱讀/理解/維護(hù)測試及其 IMO 測試的強(qiáng)制性要求。
還有一點(diǎn)需要考慮，黑盒測試比白盒測試要好得多。在您的情況下，您不返回JSONArray users，只需將其創(chuàng)建為內(nèi)部變量即可進(jìn)行內(nèi)部計(jì)算。
現(xiàn)在，理想情況下，測試應(yīng)該檢查給定輸入?yún)?shù)列表，該方法是否返回預(yù)期值，僅此而已，測試不應(yīng)該擺弄諸如“如果我想讓它通過，我必須在這里創(chuàng)建內(nèi)部值”之類的問題以這種特殊的方式，然后創(chuàng)造另一個(gè)類似的價(jià)值”。這一切都使得測試不明確且非常脆弱。
所以這里有一些“經(jīng)驗(yàn)法則”：
總是喜歡黑盒測試。不要檢查方法內(nèi)部做了什么，最好在編寫測試時(shí)甚至不要查看被測類的實(shí)現(xiàn)。
始終嘗試編寫在給定參數(shù)集的情況下實(shí)際返回某些內(nèi)容的方法 這將使測試更易于閱讀和理解
僅模擬/存根交互 - 該類需要的真正依賴項(xiàng)。通常這些并不多，而且它們出現(xiàn)在非常具體的點(diǎn)上。不要模擬內(nèi)部變量的創(chuàng)建、就地完成的靜態(tài)計(jì)算的結(jié)果或返回值。
例子：
// 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<>(..)
}
添加回答
舉報(bào)
0/150
提交
取消