在開發用戶界面時，您對使用TDD有何看法和經驗？開發UI時TDD是否適用？
我一直在思考這個問題一段時間了，只是無法達成最終決定。我們即將開始一個Silverlight項目，並且考慮TDD時考慮了Microsoft Silverlight Unit Test Framework，但我不確定如何將該方法應用於UI開發（特別是Silverlight）。
編輯： 的問題是關於它是否使用TDD的UI開發，不是怎麼辦分離關注點實事。
試圖測試UI組件的確切位置是毫無意義的。首先，因爲佈局是主觀的，應該由人類「測試」。其次，因爲隨着用戶界面的變化，你會不斷重寫你的測試。
同樣，除非您正在編寫新組件，否則不要自行測試GUI組件。相信框架來完成工作。相反，您應該測試這些組件的基礎行爲：組成應用程序的控制器和模型。在這種情況下使用TDD可以促使您分離關注點，以便您的模型真正成爲數據管理對象，並且您的控制器是真正的行爲對象，而且它們都不與UI緊密相連。
如果你將邏輯從實際的GUI代碼中分離出來，可以很容易地使用TDD來構建邏輯，如果你需要的話，在邏輯上建立另一個接口也會容易得多。
測試驅動開發更適合開發代碼，而不是開發用戶界面。 TDD有幾種不同的執行方式，但真正TDD的首選方式是首先編寫測試，然後編寫代碼以通過測試。這是在整個開發過程中迭代完成的。個人而言，我不確定你將如何去執行用戶界面的TDD;然而，我所在的團隊對我們的用戶界面進行了自動模擬測試。基本上，我們有一套模擬程序，每小時在最新的應用程序版本上運行。這些測試執行常見操作，並基於比如一組用例來驗證某些元素，短語，對話等等是否正確發生。
當然，這也有其缺點。這種情況的缺點是模擬被鎖定在代表案例的代碼中。它留下很小的差異空間，基本上說，它期望用戶執行完全此行爲相對於此功能。
一些測試比沒有測試好，但它可能會更好。
是的，您可以使用TDD對Web應用程序的GUI測試有很大的影響。
測試GUI時，通常使用存根/假數據，讓您測試gui中的所有不同狀態更改。你必須將你的業務邏輯和你的gui分開，因爲在這種情況下，你會想要嘲笑你的業務邏輯。
這對於捕捉那些測試人員總是忘記點擊的東西來說非常整潔;他們也得到測試失明！
我從用戶界面的角度來看待TDD，更多的是來自UI通過的裸露驗收標準。在一些圈子中，這被標記爲ATDD或驗收測試驅動開發。
我在使用TDD進行用戶界面時發現的最大的過度工程是我對使用自動化測試來測試外觀和感覺問題感到興奮不已。我的建議：不要！專注於測試行爲：該點擊產生這些事件，該數據可用或顯示（但不顯示它如何顯示）。外觀和感覺真的是你的獨立測試團隊的領域。
關鍵是將精力放在「高附加值」活動上。自動化樣式測試更多的是債務（保持最新）而不是增值。
根據你的編輯，這裏有一些關於我們如何在我現在的團隊中做的更多細節。我正在用GWT做Java，所以Silverlight的應用程序可能會有點關閉。
要求或錯誤進入開發人員。如果UI更改（L & F），我們快速模擬UI更改並將其發送給產品所有者進行審批。當我們在等待時，我們開始TDD過程。
我們從Web測試（使用Selenium在瀏覽器中驅動用戶點擊）至少開始，或使用Concordion，FiT或類似軟件的「無頭」功能測試。一旦完成並失敗，我們就可以對攻擊底層服務的位置有高層認識，以使系統正常運行。
下一步是挖掘和寫一些失敗的單元和集成測試（我認爲單元測試是獨立的，沒有依賴關係，沒有數據等等。集成測試是完全有線的測試，讀/寫數據庫等）
然後，我使它從下往上工作。聽起來你的TDD背景會讓你推斷這裏的優勢。重構的方式，以及...
我不能說話微軟的Silverlight，但我從來沒有使用TDD的任何佈局問題，只是不值得的時間。最好的方法是使用單元測試來檢查您實現的任何類型的接線，驗證和UI邏輯。大多數系統爲您提供對用戶所採取行爲的編程訪問，您可以使用這些來聲明您的期望得到了正確滿足。例如。調用按鈕上的click（）方法應該執行你想要的代碼。選擇列表視圖中的項目會將所有UI元素內容更改爲此項屬性...
GUI本身很難進行測試，因此Brian Rasmussen建議將對話框代碼與GUI代碼分開。
例如，您可能會有一個對話框輸入詳細信息（例如信用卡號碼），您需要驗證它們。在這種情況下，您會將檢查信用卡號碼的代碼與Luhn algorithm放入您測試的單獨對象中。 （有問題的算法只是測試數字是否合理 - 它是爲檢查轉錄錯誤而設計的。）
我認爲this blog post作者Ayende Rahien使用務實和合理的方法很好地回答了我的問題。下面是從後幾報價：
測試UI，例如，是一種常見的 地方，它是不值得的 時間和精力。
...
代碼質量，靈活性和 更改的能力是其他東西 往往歸因於測試。 他們肯定有幫助，但他們通過 並不意味着唯一的（或甚至最好的） 方式來處理。
測試只應用於他們增加項目價值而不成爲主要焦點。我終於可以肯定的是，使用測試驅動開發的用戶界面可以很快成爲許多工作的來源，這是不值得的。
請注意，這篇文章似乎主要是關於測試之後測試的東西，而不是之前（如TDD） - 但我認爲下面的黃金法則仍然適用：最重要的事情應該得到最大的努力，重要的事情應該更少的努力。擁有經過單元測試的用戶界面通常並不重要，正如Ayende所寫，使用TDD作爲開發模型的好處可能不是很大 - 尤其是當您認爲開發用戶界面通常是自頂向下的過程時。
在我的工作，我們使用TDD，我們實際上單元測試我們的UI代碼（Web應用程序）由於Apache Wicket的WicketTester但它不是測試，一些描述性標籤是文本字段或類似的東西之前，我們反而測試組件的層次結構是否正確（「標籤與文本字段相同」），並且組件是它們應該是的組件（「此標籤真的是標籤」）。
就像其他人已經說過的，確定這些組件是如何放置在UI上的，而不是程序員，特別是因爲程序員傾向於使用一體化/模糊的命令行工具的易於使用的用戶界面。
是的，這是必要的 - 但是首先使用TDD是否實用？ 在Silverlight中，客戶端通常非常薄，因此唯一需要測試的是用戶交互事件，並且數據正確綁定。 – JacobE 2008-12-12 13:15:27