自動化測試的 Design Pattern：Page Objects

過去在開發自動化測試時，常常都會思考到，我們是否需要用物件導向的方式來寫測試碼？當時主要的需求來自於：

• 自動化工具提供的元件，如果有功能不足需要擴充的部分，我們可以寫一個新的元件來繼承舊有元件，並實作額外功能

最後因為效益沒有很大，加上也可能讓程式碼變得較為複雜，就一直沒有去實現這件事。

直到看到這篇文章，才發現到其實物件導向的好處不止於此，物件導向一樣適合套用到自動化測試開發上頭。

以動作為基礎的自動化測試碼

我們過去的實作方式，是以測試案例為主體。一個測試案例包含了哪些前置條件、步驟，以及檢驗結果，我們就一一實作出來，每一個動作都是一個 function。當對程式碼做了一定程度的抽象化，每一個高階的動作其實是由一連串的低階動作所組成，實作的細節被包在底層。舉登入當例子：

Login(id, password) 可分解為以下動作：

• enterID(id)

• enterPassword(password)

• pressSubmit()

每個抓取 UI 元件填值或點選的動作，都被包在底層的 function 之中。如果有底層實作的變動，最上層的高階程式碼有很大的機會不受影響。

那這樣的做法，跟用 Page Objects 的方式實作，又有什麼差別呢？

Page Objects 建議以每個頁面 (Page) 為主體，去定義它所提供的服務。這邊「服務」指的是使用者可以透過這個頁面的元件去完成什麼事。轉化成程式碼，就是一個 class 有它的方法與屬性 (methods and properties)，「方法」就是其提供的服務，「屬性」就是頁面上的一個一個元件。

官方文件開宗明義定義了 Page Objects 的目的：

Within your web app’s UI there are areas that your tests interact with. A Page Object simply models these as objects within the test code. This reduces the amount of duplicated code and means that if the UI changes, the fix need only be applied in one place.

寫得非常清楚，它主要的目的是降低重複的程式碼，並沒有太特別，但我覺得它的好處不止於此。

以 Page 為主體建模型的好處

UI 自動化測試是一種黑箱測試。SQA 在設計測試案例之前，本來就需要對程式的 UI 介面建模型，才能設計涵蓋完整的測試案例，例如 Finite State Machine (FSM) 就是我們常用的建模方法。

每次當我們分析、建模完成後，每個 UI 頁面、以及其提供的服務就已經躍然而生。這時我們可以直接把每個頁面轉化成 class，其所提供的服務轉化成 function，非常合理！

這樣做還可以避免一個問題：我們原先的寫法，長久下來累積了非常多的大、小動作，全部都放在 Utility class 也不是辦法，不如利用 Page Objects pattern 的實作方式，去定義每個頁面提供的服務，將服務分門別類放置在所屬的 Page class 之下，結構上比較清楚。

參考資料

Page Objects on Selenium

• Automation Testing