使用Sahi測試Dojo應用(3)

　　2. 設計原則

　　接下來介紹一下我用Sahi測試Dojo應用時遵循的幾個原則。

　　1. 面向對象

　　面向對象早已不是什么新鮮事物。其實，UI自動化測試程序直覺上來講可以采用過程式的編程模式，因為它本身就是將很多行為串接起來。為什么在測試Dojo應用時要使用面向對象的理念?原因很簡單，因為Dojo Widget本身就采用了面向對象的思想。因此，在我的自動化測試框架中，每個Dojo Widget都對應于一個Javascript的“類”，不僅封裝了DOM結構而且更便于代碼重用。

　　2. 采用IBM框架(之前叫ITCL - IBM Test Community Leadership)

　　從事Web自動化測試的讀者恐怕對IBM框架不會感到陌生。IBM框架由三層組成：應用對象、任務和測試用例。潛在于應用對象、任務和測試用例包之下的基本原理是：

　　層次化的體系架構

　　將“做什么”與“如何做”分離開來

　　代碼重用

　　一致和清晰的組織結構

　　快速增強的能力

　　迅速的調試

　　有效地組織文件

　　啟用協作

　　學習他人

　　下面是對應用對象、任務和測試用例的解釋說明：

　　應用對象：儲存有關你的應用程序中的GUI元素信息。同時在這里也可以編寫你的Getter 方法，這些 Getter 方法可以返回對象，使 調用者能夠對這些GUI元素進行查詢和操作。一般情況下，這些方法在Task層中進行調用。

　　任務：在這里你將編寫可重用的方法，這些方法在你的應用程序中執行通用功能。同時在這里，你將編寫可以處理和查詢復雜的特定應用程序控件的方法。在任務中的方法可以被測試用例調用。

　　測試用例：導航一個應用程序，驗證其狀態，并記錄其結果的方法。

　　3. 借助Label識別元素

　　通常頁面上每個元素都會有一個label并且它是“可見”的。所謂“可見”，是指label的值是不需要借助于工具直接能看到的。例如id、name等，必須通過查看源碼或者一定的工具，如Firebug查看其屬性值。因此通過借助label的元素識別方法可以提高開發效率(因為你不在需要去用工具查看元素屬性值了)。

　　3. 代碼詳解

　　三個目錄appobjs，tasks以及testcases即是IBM框架中的三層架構，其中的 JobAppFormPage.sah，JobAppFormTasks.sah以及JobAppFormTests.sah分別是應用對象、任務和測試用例程序文件(Sahi腳本)。

　　Dojo Widget的封裝

　　下面以DojoWidget和Textbox兩個類為例講解Widget的封裝。

　　function DojoWidget($self) {

　　this.getLabel = function () {

　　var $widId = getAttribute($self, "widgetid")

　　_set($labelText, getLabelTextByFor($widId))

　　return $labelText

　　}

　　this.hasError = function () {

　　var $class = getAttribute($self, "class")

　　return $class.indexOf("dijitError") == -1 ? false : true

　　}

　　}

　　var $DojoTextbox = function Textbox($elem) {

　　var $self = findEnclosingWidget($elem, "dijitValidationTextBox")

　　DojoWidget.call(this, $self)

　　var $textbox = _textbox("dijitReset dijitInputInner", _in($self))

　　this.setValue = function ($value) {

　　_setValue($textbox, $value)

　　var $current = this.getValue()

　　_assertEqual($value, $current)

　　}

　　this.getValue = function () {

　　return _getValue($textbox)

　　}

　　this.blur = function () {

　　_blur($textbox)

　　}

　　}

　　core.sah中定義了所有的Dojo widget類。所有的Dojo widget類都繼承DojoWidget。DojoWidget定義了一些widget通用的函數，例如getLabel和 hasError。$self變量通過函數findEnclosingWidget獲得，這個變量代表了Dojo widget最外層的元素。此函數通過檢查父節點中是否有widgetid屬性，并且檢查class屬性的值是否包含指定的標示widget類型的字符串(例如，DojoTextbox的類型字符串是dijitValidationTextBox)來識別widget的最外層元素。Widget的繼承通過 call函數實現，它將$self傳給DojoWidget類的構造器。$textbox的識別使用了_in函數，這種方法保證了元素識別的準確性。事實上，無論一個widget本身有多復雜，通過_in函數就可以將內部元素查找與外界隔離。大家或許注意到this.setValue函數中有個比較奇怪的地方，this.getValue()的返回值是先賦值給$current變量然后進行斷言判斷的。為什么不寫成 “_assertEqual($value,this.getValue())”呢?這是因為目前Sahi不支持這樣的語句，或許將來會支持。

原文轉自：http://www.uml.org.cn/Test/201204265.asp