基于 Java™ 的 Web 開發(fā)領(lǐng)域近出現(xiàn)了豐富的競爭性技術(shù)。啟動新項目的開發(fā)人員可以在許多不同的框架之間進行選擇，包括 JavaServer Faces、Tapestry、Shale、Grails 和 Seam （只列舉眾多機靈的名稱中的幾個）。很快，我們可以通過 JRuby 框架在 Java 編程中使用 Ruby on Rails 了！

但在不遠的過去，只有一個 Java Web 開發(fā)框架卓然而立。Struts 是第一個在 Java 世界掀起風(fēng)暴的框架，而且多年以來，好像是如果一個項目不用 Struts 構(gòu)建沒有前途一樣。沒有 Struts 經(jīng)驗的 Java 開發(fā)人員很稀少，也很不幸，像的開發(fā)人員沒有聽說過 Ruby on Rails 一樣。
 
提高代碼質(zhì)量
不要錯過 Andrew 的附帶 討論組 ，可以得到迫切問題的答案。

即使 Struts 正慢慢地從舞臺中央退去（原來的基本框架，現(xiàn)在叫做 Struts 1，似乎正在退出 Web 框架的歷史舞臺），但它的遺產(chǎn)仍然存在，既以 Shale （請參閱 參考資料）的形式存在，又以運行在世界各地的成千上萬的遺留應(yīng)用程序的形式存在。因為許多企業(yè)寧愿測試和維護這些應(yīng)用程序而不愿意花錢重新編寫它們，所以理解 Struts 應(yīng)用程序的一些缺陷，以及如何圍繞它們進行重構(gòu)，是個好主意。

這個月，我要把以質(zhì)量為核心的方法用于 Struts 應(yīng)用程序的測試場景。結(jié)合現(xiàn)實，這個場景圍繞著普遍的 Struts 構(gòu)造：深受喜愛的 Action 類。

1、2、3，行動！

Struts 的革新之一是把 Web 開發(fā)從 Servlet 移進了 Action 類。這些類包含業(yè)務(wù)邏輯，以 JavaBean 的形式（通常叫做 ActionForm）把數(shù)據(jù)傳送到 JSP。然后 JSP 處理應(yīng)用程序視圖。Struts 到 MVC 的方法非常容易掌握，以至于許多開發(fā)團隊冒失地闖進去，而很少考慮與 Action 相關(guān)的長期設(shè)計和維護問題。

 
測試和復(fù)雜性

我已經(jīng)發(fā)現(xiàn)，在開發(fā)人員的測試和代碼的復(fù)雜性之間存在強烈的相關(guān)性：沒有其中一個的地方，通常也沒有另一個。高度復(fù)雜的編碼難于測試，結(jié)果是很少有人會真正為它編寫測試。反過來，編寫測試可以降低代碼的復(fù)雜性。因為給復(fù)雜代碼編寫測試更困難，而且因為會邊走邊測試，所以會發(fā)現(xiàn)自己朝著更簡單的代碼構(gòu)造前進。如果代碼太復(fù)雜，而且知道不得不測試它，您可能會在測試之前對復(fù)雜性進行重構(gòu)。不論如何看待，為不那么簡單的代碼編寫測試是消滅代碼復(fù)雜性的好實踐。

雖然在那個時候（過去的自由時光�。┛赡軟]人想過，但 Struts Action 類通常成為復(fù)雜性的保護所。像在老的 EJB 架構(gòu)中聲名狼籍的會話 Facade 一樣，Action 類會成為特定業(yè)務(wù)過程的嚴格偽裝，或者通過直接調(diào)用 EJB，通過打開數(shù)據(jù)庫連接，或者通過調(diào)用其他高度依賴的對象。Action 類還有輸出耦合（通過 java.servlet API 包中的對象，例如 HttpServletRequest 和 HttpServletResponse），從而極難把它們隔離出來測試。

隔離出來測試 Action 類的困難意味著它們可以很容易變得相當(dāng)復(fù)雜 —— 特別是當(dāng)它們變成越來越深入地與遺留框架耦合的時候�，F(xiàn)在我們來看這個困難在真實的遺留應(yīng)用程序場景中作用的情況。

測試挑戰(zhàn)

即使簡單的 Struts Action 類也會是個測試挑戰(zhàn)。例如，以清單 1 中的 execute() 方法為例；它看起來足夠簡單，可以測試，但是真的么？