我在當前的項目中使用了Specflow和WatIn進行驗收測試。客戶希望我們使用Microsoft編碼的UI。我從來沒有測試過編碼的UI，但從我目前看到的它看起來很麻煩。我想在使用ui之前預先指定我的驗收測試，而不是某些錄製/播放內容。無論如何，有人可以告訴我爲什麼我們應該丟棄Specflow/watin組合並將其替換爲編碼的UI？當我們有Specflow時，爲什麼我們應該使用編碼的UI？
我也讀過你可以將specflow和編碼的ui結合起來，但它看起來像一個很大的開銷，我已經在specflow中做得很好。
我寫了一篇關於如何做到這一點博客文章，你可能會發現有用
http://rburnham.wordpress.com/2011/03/15/bdd-ui-automation-with-specflow-and-coded-ui-tests/
編碼的UI測試中，我能想到的親的和反對的是你的測試應用程序完全用戶將如何正在使用它。這對驗收測試很有用，但它也有其侷限性。它也非常適合端到端測試。在過去的UI測試中已知是脆弱的。例如，當MS創建VS2010 UI時，幾乎所有的UI測試都失效了。主要原因在於技術的變化。編碼UI測試確實有助於通過與控件匹配的方式來限制這種情況的發生。它使用更多的基於概率的匹配。這意味着它將嘗試根據它具有的信息（例如控件名稱）來查找最佳匹配。對我們來說Coded UI測試是我們的選擇，因爲技術限制。我們的傳統應用程序是VB，雖然CUIT不太好，但我正在編寫擴展以獲得更好的控制信息，但它仍然是我們唯一的選擇。同時請記住，CUIT是新的，並有其自身的侷限性。您應該準備好佈局項目的方式，因爲維護您的UIMaps可能需要一些手動工作，這是由於VS2010中的當前端到端行爲，例如通過現有的動作記錄來創建CUIT在一個名爲UIMap.uitest的UIMap中進行測試，並且無法將其更改或轉移到另一個UIMap。如果您使用多個UI映射，這意味着您需要先記錄您的步驟，然後在測試中使用它們。不過在.net中它仍然非常靈活。
迄今爲止，關於specflow的最好的事情是它的可讀性和生動文檔的gerkin語法。通常情況下，您的應用程序的測試功能或行爲是價值的來源。它通常針對UI下方的測試。當用戶界面在這裏改變時，測試中斷的可能性就會降低。當您的應用程序處於不斷變化並且您想確保現有功能保持正常工作時，Specflow對我來說非常棒。它非常適合在Scrum環境中使用，您可以在其中編寫場景作爲其應該如何工作的描述。 specflow的一個限制我可以看到它的開放解釋。正因爲如此，編寫不太可重用且難以維護的測試很容易。我喜歡使用更通用的術語來描述我的步驟，如「以User1登錄」而不是「進入登錄頁面，輸入用戶名和密碼，單擊登錄」。描述它更加細化使得重複使用更加難以將其耦合到UI。登錄實際上如何工作應該取決於不是specflow功能的代碼。
然而，結合這兩個對我們來說似乎比僅使用編碼UI測試更有益處。如果我們決定徹底改變用戶界面，那麼我們至少應該有一種行爲，這些行爲應該以任何人都能理解的方式存儲在我們的specflow功能中。最後，您需要考慮應用程序將如何發展以及應用程序的類型。