這個問題一直在困擾我一段時間。MFC應用程序的任何可測試體系結構或設計模式？
我正在爲MFC應用程序尋找可測試的體系結構設計模式。請不要告訴我MFC已經是MVC或類似的東西，因爲只要我們無法測試應用程序，它就沒有任何意義。
我明白的經驗法則是使其視圖/文檔儘可能愚蠢， 使其他類可測試。但我想了解更多細節。我如何使View/Document儘可能愚蠢並將它們連接到其他可測試類？
首先，我想到了MVP，因爲我在Windows .NET和Android應用程序方面取得了一些成功。但在這個MFC的情況下，我們也需要使文檔變得愚蠢。這使事情變得複雜。
我需要一個可以長期維護的有效架構。任何有經驗的開發人員的建議將不勝感激
我不認爲你可能需要任何特殊的設計模式來分隔UI的邏輯。 MVP可以提供幫助，但實際上可能並不需要。如果您可以將邏輯分爲獨立的dll或靜態庫，並使其可以從其他應用程序訪問，則分離足以進行測試。這將是一個很好的開始，可以讓你的邏輯可以測試。
但即使在那之前，我會爲您的開發環境找到一個好的測試框架。我在Google測試框架或MFC的Boost測試方面取得了一些成功。
至於設計模式，它們非常好，可以使程序維護並最大限度地重用代碼，但我不確定使用它們來使程序可測試是一個好習慣。可測試性是您程序的一個很好的屬性，但它可能不是您設計的目標。
你是說MVC？它在doc/view體系結構中，但控制器部分有些遺漏。你仍然可以完成GUI和數據分離的好事，但將模型和視圖分開的真正優點是你可以在其他地方使用它，但是用doc/view來說並不容易。
編輯：附加： 至於測試功能，MFC應用程序隨附命令行處理。你可以建立它並從命令提示符發送測試命令到應用程序。
測試GUI的仍然是一個可怕的任務。有工具可以幫助您跟蹤和重放交互式輸入。我使用了一些此API（從Perl中盜取的代碼）將keypress事件注入到另一個應用程序中（以在firefox中打開一個新的url，而不總是打開一個新的標籤）。但是這對測試來說不夠好。
先進的工具成本多千美元，並與外部腳本語言和可用性報告分開來。 http://en.wikipedia.org/wiki/List_of_GUI_testing_tools
GUI測試有兩個不同的區域。一個是用用戶選項填寫對話框，另一個是模型/視圖測試。
第一個可以用幾個編碼規則輕鬆解決。例如，對話框不會修改任何內容，但可以使用所有選項並返回類。在這種情況下，您可以簡單地用自己的代碼替換對話框代碼。這是簡單的部分。在我的代碼對話框中，修改ini文件設置，然後通過一些提示通知模型有什麼變化。
測試視圖和模型非常困難。如果是關於繪圖，則可以嘗試使用WM_PRINT消息來捕獲視圖，然後運行測試並將其輸出與先前捕獲的數據進行比較。如果位圖相同，則測試通過。我從來沒有真正看到這種技術在現實世界中的應用，除了在一個工具包中用於測試多個平臺上的像素精確繪圖。
接下來是基於交互式代碼測試模型。正如之前提到的，關鍵事件更容易模擬大多數直接轉換爲分離的命令處理代碼的代碼，因此您只需測試命令而不是關鍵事件處理程序。鼠標選擇和操作，例如畫布上的對象選擇要困難得多。可以使用承諾捕獲和重放鼠標動作或祈禱的測試工具之一。
取決於您自己的代碼庫，有很多不同的方法，如果您從MFC抽象得足夠好，可以使用模擬GUI對象而不是真正的MFC窗口。如果你已經嵌入了腳本語言，可以幫助你測試的東西等。我很抱歉沒有簡單的模式。必須逐案決定。
我自己的經驗是，我不喜歡單元測試GUI和單元測試。這往往不值得。我使用了Eiffel和Design by Contract（這意味着大量斷言），並且與客戶進行廣泛的beta測試，並讓客戶找到剩餘的錯誤。無論如何，大多數錯誤都是無法測試的可用性錯誤。
不，MVP。模型視圖演示者。 – 2011-12-15 16:29:35
Mystere Man是對的我的意思是MVP。但實際上，在這種情況下它是MVP還是MVC並不重要。正如你所說，我不認爲Doc/View真的是MVC。我真正希望的是讓Doc類作爲Presenter或者Controller類來定製模型類，然後通過單元測試Doc類來測試UI邏輯。 – 2011-12-15 16:41:35