.NET UI測試（單元和集成）

Question

我的任務是提出在UI級別上進行有效單元測試和集成測試的解決方案。不幸的是，我們在windows窗體中有很多代碼隱藏。我們還有一個棕地項目，我們正在慢慢轉向WPF（新功能在WPF中，當他們保證重大更改時，將舊功能移到WPF）。

WPF中的所有內容都是單元測試（數據庫除外）。我使用MVVM方法，因此幾乎所有的代碼都在那裏。

但是，在部署之前進行測試需要很長時間，我們需要一種自動化大部分時間的方法。

也就是說，我所指的這個測試需要在用戶界面上進行。

Windows窗體部件必須進行集成測試，因爲部分邏輯是在代碼隱藏中完成的，部分在數據庫中完成。

WPF窗口應該在UI級別進行單元測試，但也要進行集成測試。

我知道這對於一個問題有很大的吸引力，但是有沒有人有任何建議？

Answer 1

（這個答案是關於如何整合測試代碼：WinForms和WPF）

我沒有給你一個專利解決方案，只是建議投入了大量的時間和精力投入使測試易於維護。

確保您可以在Visual Studio中修改並運行測試。

不得不爲測試啓動一個不同的工具的額外burdon可能足以讓開發者不這樣做（我見過它發生）。所以試着找到允許這個的UI testing tool。

不要記錄測試。

舒適，記錄測試的結果代碼很難閱讀和理解，並且很可能包含許多不重要的細節。如果您需要對測試進行更改，您可能需要重新錄製它們。測試將更多地是關於系統如何工作的文檔，而不是您希望如何工作的規範。

爲您的測試創建共享基礎架構。

爲表示窗口行爲的對象中的窗口/窗體創建抽象。通過這種方式，您可以隱藏這些對象中的實現細節，使實際測試更加緊湊並且易於閱讀。一旦你有了這個基礎設施，就可以很容易地添加新的測試。此外，如果實施細節發生變化，您只能在一個地方對測試進行更改：在基礎架構中。

在網絡測試世界中，這被稱爲page object pattern。在C＃中測試的

例子：

ApplicationFake application = new ApplicationFake(); 

// ApplicationFake.Start() starts the application resulting in that main form opens. 
// Start() returns an object that represents the actions that the user can perform on 
// the main form. 
// The Start() method might contain an assert that the main form was actually opened. 
MainFormFake mainForm = application.Start(); 

// Performing an action that opens a new form returns a representation of the new form, 
// in this case the object SomeFormFake. 
SomeFormFake someForm = mainForm.ClickOpenSomeFormButton(); 

// The form fakes exposes properties that returns the forms' observable state. 
Assert.That(someForm.Title, Is.EqualTo("Some Form's Title")); 

Answer 2

我完全Torbjorn的答案同意，但想補充幾點：

開始小

頁面對象圖案是很好的方法來簡化你的測試，但是你會發現獲得抽象是需要很長時間的。首先抽取你需要的東西，然後慢慢加入。

增加價值

不要走極端，並嘗試寫終端到終端的迴歸測試。相反，專注於編寫增值的測試。例如，一個演示應用程序啓動沒有錯誤的單個測試非常有用，可以爲您的構建過程提供早期反饋。從那裏出來。

平衡「深」與「淺」

有用於測試用戶界面的幾個不同的理念。建立它們之間的混合。

顯而易見的方法是使用類似生產的設置來測試應用程序，以證明應用程序「從前到後」工作。這些是「深層次」的集成測試，可以鍛鍊代碼的所有部分並且很有用。由於它們通常依賴於外部服務等，它們也可能會非常緩慢。通常，爲了保證可靠性，應用程序必須在測試運行之間重新啓動以確保有效的環境。

該方法稍作修改就是測試應用程序與殘缺服務（假冒產品目錄，假身份驗證提供程序等）。這些是「淺」測試，它們表明用戶界面在集成在一起時起作用。他們通常運行更快一點，因爲他們不會有相同的物理約束，如網絡延遲考慮。您可以更多地關注演示文稿細節和其他邊緣案例。

進一步的修改是隔離部分用戶界面並在測試工具中運行它們。這些測試的運行速度比以前的方法快得多，因爲它們不會具有啓動整個應用程序的相同開銷。使用這些測試來確定顏色和高度專業化的演示問題。

迭代時穩定

如果您打算編寫功能測試，以取代手工迴歸測試你可能會發現，最好等到發展爲它編寫自動化之前穩定該功能。如果您在開發過程中開始編寫自動化程序，您將不斷重新編寫測試。如果您想在開發過程中自動化，請記住：從小處着手。

獲取早期反饋

的UI（也稱爲功能測試）的自動化測試是有用的，但它可以是非常，非常緩慢。 （我已經看到運行需要幾個小時才能完成。）如果你每天運行一次整個測試套件，你會發現反饋循環太長，導致誤報和維護問題等。

儘可能將功能測試集成到構建過程中。如果測試套件花費太長時間，請找到一種方法來集成的一些測試，以便您的構建管道可以驗證重要測試作爲構建的一部分。