Static 實用程序 Class，單元測試和 Java.Time

Question

由於我們的客戶仍在使用 Java.Date.Util，我們不得不處理各種轉換方法和大型臃腫的日期實用程序 class。 我的目標是簡化實用程序 class 並為其編寫單元測試。

我已經設法簡化它，但我遇到了測試用例的問題，因為：

1. 作為實用程序 class，方法是 static，因此不使用 Java.Time.Clock 進行依賴注入。
2. 我們的幾個輔助方法在將其轉換為請求的格式之前使用了 instant.now()。 顯然這使得編寫單元測試......有問題。

以下是我需要為其編寫測試用例的一些方法示例：

     /**
     * Get the current time in any format.
     * @param outFormat
     * @return
     */
    public static Object getNow(TimeFormat outFormat){
        Instant dateObject = Instant.now();
        
        return new InstantConverter().convertTo(dateObject, outFormat);

    }
    
    /**
     * @param value - unit of time 
     * @param unit  - hours, days, etc. Anything higher than days is not supported. 
     * @param format - format returned. 
     */
    public static Object calculateFutureDate(int value, ChronoUnit unit, TimeFormat outFormat) {
        Instant time = Instant.now().plus(value, unit);
        
        return new InstantConverter().convertTo(time, outFormat);
    }

InstantConverter是一個受保護的 class，它將 Instant 轉換為各種時間輸出（本地日期、字符串、紀元、java.util.date 等），而TimeFormat是一個枚舉，包含我們可以轉換的所有格式。

我知道在單元測試方面遠離 static 方法是最佳實踐……但恐怕這不是一個選擇。

在我的研究中，似乎我唯一的選擇是使用 powermock 或 mockito 的更高版本之一來模擬我的 static instant.now() 方法（類似於：Z5E056C500A1C4B6A7110B50D807BADE5 mockito-java-kotlin/ ）。

我只是想確保我沒有遺漏任何明顯的東西，因為我犯了一個錯誤，我不想再次重構。

感謝任何花時間閱讀本文的人。 如果您有任何問題，請告訴我。

Answer 1

沒有什么可以阻止您將Clock注入包含 static 實用程序方法的 class 中。

1. 聲明一個private static Clock字段（一個 class 變量）。 在聲明中將其初始化為Clock.systemUTC()或Clock.systemDefaultZone() 。
2. 讓您的 static 時間敏感方法使用剛剛介紹的Clock 。
3. 有一個 package 私有（默認可訪問） static inject或setClock方法將Clock注入 static 變量。
4. 如果需要，可以使用uninject方法將Clock設置回其初始值。

將您的單元測試保持在相同的 package 中，以便他們可以使用 package 私有注入方法。 您可能已經知道，測試 static 實用程序方法的測試方法首先注入其所需的Clock ，然后調用該方法進行測試並驗證該方法的返回值。 由於Clock為 static，因此無法並行運行測試。