爲單元測試添加受保護方法的好習慣？

說我有以下類：爲單元測試添加受保護方法的好習慣？

public class ProblematicObject { 
    public static void methodToTest() { 
     SomeDependency dep = DependencyGetter.getDependency(SomeDependency.class); 
     dep.doStuff(); 
    } 
}

它是一個可以接受的做法進行修改和添加方法這個類進行單元測試的清潔劑（又名避免PowerMock）的緣故？下面是上面的類會是什麼樣子：

public class ProblematicObject { 

    // new 
    private static SomeDependency dep; 

    // updated 
    public static void methodToTest() { 
     getSomeDependency().doStuff(); 
    } 

    // new 
    private SomeDependency getSomeDependency() { 
     if (this.dep == null) { 
      return DependencyGetter.getDependency(SomeDependency.class); 
     } 
     return dep; 
    } 

    // new, only used for testing, not in any impl code 
    @Deprecated 
    protected void setDependencyGetter(SomeDependency dep) { 
     this.dep = dep; 
    } 

}

我似乎記得讀書的地方，增加了測試的目的方法（而不是重構的問題類）被看不起。

來源

2017-10-13 Ampp3

檢查這個問題，那裏有很多意見。 [我如何測試具有私有方法，字段或內部類的類？]（https://stackoverflow.com/questions/34571/how-do-i-test-a-class-that-has-private-methods -fields - 或內 - 類）。在我看來私人方法應該通過已有的公共方法來測試。僅僅爲了測試而添加方法味道不好，並且改變測試的可見性是等待發生的潛在錯誤。 –

我個人認爲它會打破單元測試的目的，專門爲單元測試更改代碼。一般來說，單元測試的想法是在預期用於上下文的上下文中測試代碼。我不認爲每個類和每個方法都需要有單元測試用例。我建議退後一步，查看這些私有方法/變量正在使用的上下文/工作流程，並可能爲該工作流程創建功能單元測試。 – Steve

'@ Deprecated'註釋是一個很好的接觸;） –

在這個特殊的例子中，你實際上是通過使它成爲可測試的來改進你的課堂設計。

這個新的單元測試讓你從ProblematicObject的客戶端角度思考，並讓你提供了一種注入依賴的方法。

來源

2017-10-13 18:02:35 alayor

但是因爲'ProblematicObject'會更好地通過*構造函數注入*來獲得'SomeDependenc'。 'getDependency（）'不應該是'DependencyGetter'中的'static'方法... –

爲單元測試添加受保護方法的好習慣？

回答

相關問題