如何設計單元測試的類

Question

我有一個如下的Java類：

public class MyClass {

    /** Database Connection. */
    private dbCon;

    public MyClass() {
        dbCon = ...
    }

    public void doSomethingWith(MyData data) {
        data = convertData(data);
        dbCon.storeData(data);
    }

    private MyData convertData(MyData data) {
        // Some complex logic...
        return data;
    }
}

由於此類的真正邏輯在於convertData()方法，因此我想為此方法編寫一個單元測試。 所以我讀了這篇文章

如何測試私有函數或具有私有方法，字段或內部類的類？

很多人說需要測試一種私有方法是一種設計氣味。 如何做得更好？

我看到2種方法：

1. 使用公共api將convertData()方法提取到某些實用程序類中。 但是我認為這也是一個壞習慣，因為這樣的實用程序類將違反單一職責原則，除非我創建的實用程序類可能只有一種或兩種方法。

2. 編寫第二個允許注入dbCon構造函數，該構造函數允許我注入數據庫連接的dbCon版本並針對公共doSomething()方法運行測試。 這將是我的首選方法，但同時也討論了關於模擬的需求也是一種代碼味道的問題。

是否有關於此問題的最佳做法？

Answer 1

使用公共api將convertData（）方法提取到某些實用程序類中。 但是我認為這也是一個壞習慣，因為這樣的實用程序類將違反單一責任原則，除非我創建的許多實用程序類可能僅使用一種或兩種方法。

您對此的解釋是錯誤的。 這正是SRP和SoC （關注分離）所建議的

public interface MyDataConverter {
    MyData convertData(MyData data);
}

public class MyDataConverterImplementation implements MyDataConverter {
    public MyData convertData(MyData data) {
        // Some complex logic...
        return data;
    }
}

現在可以單獨和獨立於MyClass來測試convertData實現

編寫第二個允許注入dbCon的構造函數，該構造函數允許我注入數據庫連接的模擬版本並針對公共doSomething（）方法運行測試。 這將是我的首選方法，但同時也討論了關於模擬的需求也是一種代碼味道的問題。

又錯了。 研究顯式依賴原則。

public class MyClass {
    private DbConnection dbCon;
    private MyDataConverter converter;

    public MyClass(DbConnection dbCon, MyDataConverter converter) {
        this.dbCon = dbCon;
        this.converter = converter;
    }

    public void doSomethingWith(MyData data) {
        data = converter.convertData(data);
        dbCon.storeData(data);
    }
}

MyClass現在對執行所需功能所需的內容更為誠實。

還可以通過注入模擬依賴來單獨進行單元測試。