測試意圖的體現不僅僅是在行為的描述上，同樣還有測試數據，比如如下兩段代碼：
on LoginPage do login_as :name => 'userA', :password => 'password' end assert on WelcomeRegisteredUserPage registered_user = {:name => 'userA', :password => 'password'} on LoginPage do login_as registered_user end assert on WelcomeRegisteredUserPage測試的是同一個東西，但是顯然第二個測試更好的體現了測試意圖：使用一個已注冊的用戶登錄，應該進入歡迎頁面。我們看這個測試的時候，往往不會關心用戶名啊密碼啊具體是什么，我們關心它們表達了怎樣的測試案例。我們可以通過DataFixture來實現這一點：
module DataFixture USER_A = {:name => 'userA', :password => 'password'} USER_B = {:name => 'userB', :password => 'password'} def get_user identifier case identifier when :registered then return USER_A when :not_registered then return USER_B end end end在這里，我們將測試案例和具體數據做了一個對應：userA是注冊過的用戶，而userB是沒注冊的用戶。當有一天，我們需要將登錄用戶名改為郵箱的時候，只需要修改DataFixture模塊就可以了，而不必修改相應的測試：
include DataFixtureDat user = get_user :registered on LoginPage do login_as user end assert on WelcomeRegisteredUserPage當然，在更復雜的測試中，DataFixture同樣可以使用真實的數據庫或是Rails Fixture來完成這樣的對應，但是總體的目的就是使測試和測試數據有效性的耦合分離：
def get_user identifier case identifier when :registered then return User.find '....' end end 4.Navigator與界面元素類似，URL也是一類易變且難以表達意圖的元素，因此我們可以使用Navigator使之與測試解耦。具體做法和Test Data相似，這里就不贅述了，下面是一個例子：
navigate_to detail_page_for @product on ProductDetailPage do .... end 5. Shortcut前面我們已經有了一個很好的基礎，將Selenium測試與各種脆弱且意圖不明的元素分離開了，那么最后shortcut不過是在蛋糕上面最漂亮的奶油罷了——定義具有漂亮語法的helper：
def should_login_successfully user on LoginPage do assert_equal 'Welcome!', welcome_message login_as user end assert on WelcomeRegisteredUserPage end然后是另外一個magic方法：
def given identifer words = identifier.to_s.split '_' eval "get_#{words.last} :#{words[0..-2].join '_'}" end之前的測試就可以被改寫為：
def test_should_xxxx should_login_successfully given :registered_user end這是一種結論性的shortcut描述，我們還可以有更behaviour的寫法：
def login_on page_type on page_type do assert_equal 'Welcome!', welcome_message login_as @user end end def login_successfully on WelcomeRegisteredUserPage end def given identifer words = identifier.to_s.split '_' eval "@#{words.last} = get_#{words.last} :#{words[0..-2].join '_'}" end最后，測試就會變成類似驗收條件的樣子：
def test_should_xxx given :registered_user login_on LoginPage assert login_successfully end總之shortcut是一個無關好壞，只關乎想象力的東西，盡情揮灑Ruby DSL吧！
結論Selenium是一個讓人又愛又恨的東西，錯誤地使用Selenium會給整個敏捷團隊的開發節奏帶來災難性的影響。不過值得慶幸的是正確地使用Selenium的原則也是相當的簡單：
通過將脆弱易變的頁面元素和測試分離開，使得頁面的變化不會對測試產生太大的影響。 明確指定測試數據的意圖，不在測試用使用任何具體的數據。 盡一切可能，明確地表達出測試的意圖，使測試易于理解。當然，除了遵循這幾個基本原則之外，使用page object或其他domain based web testing技術是個不錯的選擇。它們將會幫助你更容易地控制Selenium測試的規模，更好地平衡覆蓋率和執行效率，從而更加有效地交付高質量的Web項目。
此文中涉及的都是我最近幾周以來對Selenium測試進行重構時所采用的真實技術。感謝Nick Drew幫助我清晰地劃分了Driver、 Page、Nagivator和Shortcut的層次關系，它們構成我整個實踐的基石；感謝Chris Leishman，在和他結對編程的過程中，他幫助我錘煉了Ruby DSL；還有Mark Ryall和Abhi，是他們第一次在項目中引入了Test Data Fixture，使得所有人的工作都變得簡單起來。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
