帶有副作用的單元測試方法

據我所知「單元測試不應該測試內部實現細節以便不會使該方法的重構複雜化」。那麼，我該如何測試這種方法呢？帶有副作用的單元測試方法

deleteOrder = (order) -> 
    backendService('deleteOrder', order.id) 
    cacheOfOrders.delete(order)

從我的單元測試環境（茉莉花），我可以打電話deleteOrder和模擬後端電話，但我不能訪問到cacheOfOrders。我想檢查一下cacheOfOrders.length是否縮小了。也許我做錯了，我不應該測試內部細節，但是如果我有一個像前一個方法但沒有後端調用的方法呢？

來源

2015-02-24 Enrique Marcos

你可以創建一個'cachOfOrders'對象作爲一個單獨的測試，你可以運行嗎？ – gmiley 2015-02-24 19:52:14

cacheOfOrders對於有問題的服務是私有的。我無法訪問或參考它。 – 2015-02-24 19:58:07

我的意思是，什麼是cacheOfOrders的一個實例？你可以測試該類的新實例，而不是通過實際實現它的內部工作來測試它嗎？如果它是開發人員創建的自定義類，則應該對其進行測試。如果它是框架提供的標準類，則不需要打擾它。 – gmiley 2015-02-25 12:15:58

靈活的解決方案可以讓你的緩存成爲一個可注入的參數，不管你在這裏做什麼，所以你可以傳遞一個模擬緩存對象，然後你可以測試。

除此之外，您是否有一種方法可以用來從緩存中查找訂單？您可以斷言在您撥打deleteOrder後，緩存不會返回有效的條目。如果您的查找在緩存中存在項目時避免了後端服務調用，那麼您可以進行測試以確保在刪除之後，查找調用確實會觸發後端服務（這意味着緩存未被填充）。也就是說，測試緩存正常運行的效果，而不是測試緩存本身。

來源

2015-02-24 19:58:49

我沒有寫這個方法，我是「單元測試團隊」（呃）的一部分。緩存不可訪問，它沒有任何公共接口......我開始認爲緩存是一個非常內部的細節。 – 2015-02-24 20:16:55

帶有副作用的單元測試方法

回答

相關問題