追求代碼質量: 測試 Struts 遺留的應用程序

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

但就在不遠的過去，只有一個 Java Web 開發框架卓然而立。Struts 是第一個在 Java 世界掀起風暴的框架，而且多年以來，好像是如果一個項目不用 Struts 構建就沒有前途一樣。沒有 Struts 經驗的 Java 開發人員很稀少，也很不幸，就像今天的開發人員沒有聽說過 Ruby on Rails 一樣。

提高代碼質量 不要錯過 Andrew 的附帶 討論組 ，可以得到最迫切問題的答案。

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

這個月，我要把以質量為核心的方法用于 Struts 應用程序的測試場景。結合現實，這個場景圍繞著最普遍的 Struts 構造：深受喜愛的 Action 類。

1、2、3，行動！

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

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

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

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

測試挑戰

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

原文轉自：http://www.anti-gravitydesign.com