單元測試WCF對域對象的響應

從WCF服務中，我們得到了一個具有多個嵌套列表和很多屬性（最多5層深）的退出複合響應。這種響應不是一對一可用的，因此我們構建了將其「翻譯」爲我們可以在UI中使用的域對象的翻譯器。單元測試WCF對域對象的響應

我們想單元測試翻譯過程，所以我們知道在字段之間沒有誤映像。目前在我的單元測試中，我正在構建代碼中的響應。但是這退出了一些工作，特別是當我在不同的響應中需要一些變體來測試不同的流量時。單元測試也成爲非常大的文件。（只有建立一個響應可以達到200行以上）

我一直在想辦法讓它更容易建立反應，並使我的unittests看起來更乾淨。

我一直在想的一個選擇是爲每個unittest創建一個具有所需響應的XML文件，將其反序列化爲響應並對反序列化的對象執行我的單元測試。

這種方法的親是unittests會變得更小，更容易創建。但更新文件/元素將會更困難。或者至少這是我的想法。

任何人有一些想法或不同的選項，使這種響應建設更容易？

來源

2012-01-02 ChristiaanV

重構API以便以「更乾淨」的方式公開數據不會那麼容易。 – Lloyd 2012-01-02 11:41:03

我沒有選項來更改傳遞數據的WCF服務。除此之外，我需要來自不同級別的數據來構建我的域對象。 – ChristiaanV 2012-01-02 11:43:44

您可以使用框架（如AutoFixture）幫助您創建響應的實例。 AutoFixture將自動設置屬性，從而使您的構建代碼非常短，您可以在需要時覆蓋其行爲。例如：

var mc = fixture.Build<MyResponseClass>() 
    .With(x => x.SomeProperty, "SomeValue") 
    .CreateAnonymous();

對於非自定義值，Autofixture使用確定性的隨機性來產生價值，這能確保你每次得到不同的值，但仍保持在有效範圍內的值。

來源

2012-01-02 11:46:16

謝謝，我會看看這個框架。 – ChristiaanV 2012-01-02 11:48:06

我認爲Lloyd的意思是，你將你當前的代碼負責構建你的響應對象並將它打包在一個單獨的* .dll中，這樣它就是一個API或一個庫，然後你可以從你的內部調用單元測試。因此你的單元測試將變得更簡單。這種方法的另一個好處是可以實際構建兩個API：一個構造假對象，另一個構造查詢真實服務。使用界面，您可以通過配置設置輕鬆切換API。你也可以嘗試使用像MoQ或者smth這樣的模擬框架。如果它對你的情況有意義。

來源

2012-01-02 12:00:09 dotnetPr0

這似乎並沒有減少我的工作;） – ChristiaanV 2012-01-02 12:05:58

你會做一次這項工作，然後在其他測試中使用你的API。如果你需要更多的功能，你將不得不擴展它。所以是的，還有一些工作還需要完成。你所做的事情並不是最簡單的:)。但這種方式提供了一個更好的可維護性，包含了構建假物體的擔憂。 – dotnetPr0 2012-01-02 12:20:25

在爲請求響應接口編寫測試時，應編寫測試用例，以便每個用例在可能的情況下測試請求的最重要部分。也就是說，每個測試用例應該一次測試請求中的一個重要元素。

如果您遵循這個模式，你可以應該能夠識別每個測試用例爲下列之一：

核心案件

，從定義了「基地」的情況下哪些其他測試被構建。這些都是代表成功請求的成功案例。你可以在你的單元測試類中定義一個核心請求，或者如果你有幾個核心情況，從一個公共基礎構建核心案例。在任何一種情況下，這些情況都是你在做大部分「設置」值的地方。

偏差例

這是建立斷核心試驗的情況下，通過改變信息，以測試不同的使用情況下，片的一個的情況下。通常這些都是你的邊緣情況，並且通常測試預期的失敗（即，調用者傳遞不良信息）。

這基本上歸結爲DRY，因爲您的核心案例定義了測試用例中「常見」的東西，因此您不會花費200行來設置值。大多數的測試用例輸入要表達的，所以你應該把它們寫這樣「爲<測試用例>但<偏差>同」。

來源

2012-01-02 12:37:35

單元測試WCF對域對象的響應

回答

相關問題