測試複雜的自定義WinForms控件

我正在開發相當複雜的.NET自定義控件（40K行代碼），但在測試時遇到了一些麻煩。測試複雜的自定義WinForms控件

我已經完成了幾個示例項目，演示了控件的主要特徵，但是我們只能測試控件狀態和操作的一小部分。

單元測試也沒用，因爲這些問題：用例

巨大的數字（例如描述「項目選擇」可以採取一些4頁規格的）
許多做同樣的方式事情（也是從用戶代碼或GUI）
控制有許多國家的一個子狀態，以及任何可能不可能在每一個國家工作
如何測試設計時支持？

我知道這是GUI測試的一個共同的問題，所以我想問問你如果有任何測試自定義可視組件精心estabilished做法？

感謝您的任何建議。

來源

2011-04-20 Libor

最主要的是將GUI測試限制到最低限度，因爲它是測試成本最高的方法。在40K行代碼中，我打賭90％的代碼根本不能與WinForm GUI元素一起工作。所以大部分都可以通過單元測試覆蓋，但這取決於您構建代碼的方式。

需要考慮的事情：

SOLID原則，特別是單一職責原則（SRP） - 而不是幾個巨大的「上帝」類，你應該依靠大量的小「服務」界面&只做一件事，做得很好的類。你可以編寫獨立的測試，然後將它們組裝成更大的圖片，一旦你知道它們工作正常。
MVP模式（實際被動查看）：WinForm GUI代碼應該只是一個薄層（View），其他所有內容都應該在Presenters和Model中。
Presenter First approach。

我在relatively complex WinForms application工作，這些模式都從未失敗過我。

至於GUI測試，我使用UI Automation，但只適用於一些標準的情況。其他一切都由非GUI單元測試覆蓋。

來源

2011-04-20 16:27:02

謝謝。我實際上在一個非常不規則的[ListView-like]（http://www.componentowl.com）組件上工作（包含幾個「視圖」，每個視圖都有不同的表現）。你是對的，單元測試實際上可以覆蓋的大部分代碼都認爲某些類很難測試（例如，用於增強文本測量的類和用於重繪的優化）。我會看看「Presenter First approach」 - 看起來很有趣。像SOLID和MVP等其他原則已經或多或少地納入代碼中。 – Libor 2011-04-21 15:03:40

測試複雜的自定義WinForms控件

回答

相關問題