譯者注：這篇文章翻譯自馬丁·福勒（Martin Flower，對，沒錯，就是軟件教父）官網的一篇文章，原文出處在文底。如果你正在做WEB自動化測試，那么我強烈推薦你看這篇文章。另外透露Martin Flower將于10月份左右來成都ThoughtWorks辦公室，大家有機會一睹他的風采。
當你在為web頁面編寫測試時，你需要操作該web頁面上的元素來點擊鏈接或確定顯示的內容。然后，如果你在測試代碼中直接操作html元素,那么你的代碼是機器脆弱的，因為UI會經常變動。一個page對象可以封裝一個html頁面或部分頁面，通過提供的應用程序特定的API，你可以操作頁面元素而不需要在HTML中四處搜尋。
page對象的一個基本的經驗法則是page對象應該允許軟件客戶端能夠做任何人類能做的事。它也應當提供一個易于編程的接口,并隱藏窗口中低層的部件。所以訪問一個文本框，可以通過一個訪問方法獲取一個字符串，復選框應當使用布爾值，按鈕應當被表示為行為導向的方法名。page對象應當封裝所有的在gui控件本身上查找和操作數據的方法。一個好的經驗法則是即使改變具體的控制，這種情況下page對象接口不應當發生變化。
盡管該術語是”頁面“對象，并不意味著給每個頁面都要建立一個這樣的對象，但頁面有重要意義的元素除外[1]。所以一個顯示多個相冊的頁面可以有一個相冊列表的page對象，里面包含了幾個相冊page對象。也有可能會有一個頁眉page對象及一個頁腳page對象。經驗法則是給通過給頁面建模，從而對應用程序的使用者變得有意義。
同樣，如果你導航到另一個頁面，初始page對象應當返回另一個page對象作為新頁面[2]。一般page對象的操作應當返回 基本類型（字符串，日期）或另一個page對象。
有一個意見分歧的地方是page對象是由應當包含自身的斷言，或者僅僅提供數據給測試腳本來設置斷言。在page對象中包含斷言的倡導者認為這有助于避免在測試腳本中出現重復的斷言，可以更容易的提供更好的錯誤信息，并且提供更接近TellDontAsk風格的API。不在page對象中包含斷言的倡導者則認為包含斷言會混合使用斷言邏輯訪問頁面數據的職責，并且導致page對象過于臃腫。
我贊成在page對象中不包含斷言。我認為你可以通過為常用的斷言提供斷言庫的方式來消除重復。這可可以提供更好的診斷。[3]
page對象通常用于測試中，但自身不應包含斷言。它們的職責是提供對基本頁面狀態的訪問。而與測試客戶端實現斷言邏輯。
我所描述的這個模式針對HTML，但同樣的模式也同樣適用于任何UI技術。我見過這種模式有效的隱藏了Java swing UI的細節，并且我深信它已經被廣泛的應用于幾乎所有其他的UI框架。
并行問題是另一個page對象可以封轉的話題。這可能涉及異步操作中隱藏不作為異步呈現給用戶的異步性。也有可能涉及封裝UI框架中你不得不擔心的UI和工作線程之間分配行為的線程問題。
page對象在測試中的使用非常常見，但是也被用于在應用程序上層提供一個腳本接口。最好將腳本接口置于UI下層，這樣腳本通常不復雜并且執行速度快。然而應用程序在UI層有太多的行為，那么使用page對象可能在槽糕的工作中最好的選擇。（但是盡量將邏輯移入page object，長期來看會導致更好的腳本即更健康的UI。）
使用一些領域特定語言來書寫測試非常普遍，比如Cucumber或一門內部DSL。如果你盡量在page對象層級之上編寫測試DSL，那么你可以通過一個解析器將DSL聲明轉換為調用page對象。
如果你在測試方法中使用了WebDriver API，那么你做錯了 – Simon Stewart.
模式有助于將邏輯從頁面元素中剝離（例如 Presentation Model, Supervising Controller, 及Passive View),從而少通過UI做測試，并且減少對page對象的需要。
page對象是封轉的一個典型示例。它們從其它組件（如測試）部件中隱藏了UI結構的細節。。如果你自問“我如何能從軟件測試中隱藏細節？”，當你做開發時在這樣的情況采用page對象不失于一個好的設計原則。封轉體現了兩方面的好處。我已經強調，通過將操作UI的邏輯限制到單個地方有助于你修改邏輯而不影響系統的其他組件。一個間接的好處是使測試端代碼更容易理解，因為邏輯是關于測試的意圖，而會被UI細節搞亂。
進一步閱讀
I first described this pattern under the name Window Driver. However since then the term “page object” was popularized by the Selenium web testing framework and that’s become the generally used name.
我剛開始將這種模式命名為窗口驅動(Window Driver)。然而自從Selenium web測試框架使用“page object”這個名稱，page對象變成了常用的名稱。
Selenium的維基強烈推薦使用page對象，并提供了如果使用的建議。它也贊成page對象不包含斷言。
致謝
Perryn Fowler, Pete Hodgson及Simon Stewart為這篇博客的草稿提供了及其有用的意見。同樣像往常一樣我非常感激ThoughtWorks軟件開發列表中的各種各樣的居民提供的建議和修正。
腳注
有觀點認為”page對象“名稱是一個誤導。因為它讓你認為一個頁面只能有一個page對象。類似面板對象可能會更好，但是page對象已經被廣泛接受。為什么命名的另一個例證是TwoHardThings中的其中之一。
page對象負責創建其他的page對象（比如導航）是共同的意見。然而，一些從業者更喜歡page對象返回一些通用的瀏覽器上下文，通過建立在上下文上層的page對象的測試控制是基于測試的流程（特別是條件流）. 他們偏好基于測試腳本知道那個頁面是期待的下個頁面這一事實，并且該知識不需要在page對象之間重復。特別是使用靜態類型語言通常以類型標記的方式顯示頁面導航，這樣會增加他們的喜好。
page對象中包含斷言也行，盡管大多數人（比如我）更青睞無斷言風格。這些斷言可以檢查頁面或應用程序在此時此刻的不變量，而不是測試探索的具體東西。
文章列表
留言列表
