單元測試多個依賴關係的WCF服務

Question

我當然希望有人能幫助緩解我的沮喪。我試圖找到一種很好的方式來單元測試我的WCF服務實現類，但是我發現提供解決方案的每個資源都僅限於只有一個方法/操作的服務。

在我的情況，我有一個服務類，其中包含幾個服務方法/操作。服務類的目的是爲在覈心應用程序中實現的行爲提供接口。這樣，每個方法/操作是負責：

1. 接受來自 呼叫者
2. 驗證對象的屬性
3. 創建 適用命令對象的一個​​實例的是 執行的動作的請求對象
4. 將請求對象的 屬性映射到Command對象。
5. 執行命令對象
6. 結果映射到響應 對象
7. 返回響應給調用者

另外，該服務方法處理髮生的，並且返回一個WCF故障的任何異常。

我們對IoC（DI）和AOP都使用Spring.NET。服務類由Spring實例化，它允許我們使用Spring的ParameterValidation方面來執行第2步。默認情況下，我們也使用Spring來執行第3步。

大多數情況下，所有這些工作都很棒。但是，當編寫單元測試來驗證服務方法的行爲時，我會陷入困境，試圖找出正確的方法來處理服務對多個Command對象（每個方法一個）的依賴關係。我們要清楚，我沒有嘲笑Command對象（我們使用Moq，btw）的問題，也沒有做黑盒測試的問題。我試圖對內部邏輯進行白盒測試，例如驗證步驟4是否正確執行，或者如果Command對象引發異常，則該服務會正確處理它。對於這些我使用Command對象的模擬實例。

問題是爲被測對象具有多個依賴關係的情況尋找最佳實踐 - 特別是當我僅對其中一個測試對象感興趣時，我正在運行該測試。

DI的構造函數方法並不實用，因爲我需要爲構造函數提供儘可能多的參數，因爲我在服務上執行的方法（這可能相當多）。二傳手的注入與我有關，因爲二傳手只會出於測試的目的而存在 - 而且，在很多情況下，它們也會有很多。

該服務旨在將步驟4委託給虛擬方法，默認情況下，該方法使用Spring來實例化Command對象，但van被覆蓋以使用繼承 - 覆蓋方法返回模擬。但是這也被證明是笨拙的。

因此，在文章上線之後涌出文章，展示各種解決方案，但正如我所說的，只用一種方法/操作反映服務，我正在尋找一些易於實現的方法的指導，在處理包含多個方法和多個依賴關係的實際服務時進行維護和擴展。

請記住，我不能使用Spring來注入mocked Command對象，因爲我需要引用mock來設置它們並驗證方法的行爲。 （更不用說我的測試也依賴於Spring的正常工作了。）

Answer 1

聽起來像你已經完成了大部分的辛勤工作。

由於您已經在使用DI容器，因此您可以簡單地創建並注入攔截第3步的Mocks。然後，您可以接受DI容器接收的內容以及驗證如何執行以測試前兩個步驟，然後您可以模擬會返回你想要測試其餘步驟的任何東西。

你已經對spring.net有了很大的依賴，並且爲了注入你的嘲諷和強制測試來使用它們聽起來很合理。必須有一種方法來臨時修改你的配置以使用特定的模擬。如果不考慮一個簡單的工廠被你的服務用來讓你的Mocks到位。

Answer 2

我通常將我的服務類作爲實際功能的薄外殼。在這種情況下，你可能會考慮放棄測試服務本身，但讓它將所有調用委託給多個內部對象中的一個，這些內部對象將更具可測性，因爲它們更具體。