使用 Galen 框架進行佈局測試的藝術

已發表: 2022-03-10

快速總結 ↬在設計圖形用戶界面時，總是有一個懸而未決的問題：我們如何對其進行自動化測試？ 我們如何確保網站佈局保持響應並在各種分辨率的各種設備上正確顯示？再加上動態內容、國際化和本地化要求帶來的複雜性，這成為一個真正的挑戰。在本文中，我將引導您了解一種有趣的新佈局測試技術。使用Galen 框架，我將提供一個詳細的教程，用於編寫有意義的通用佈局測試，可以在任何瀏覽器和任何設備上執行，同時用作設計文檔中的單一事實來源。

在設計圖形用戶界面時，總是有一個懸而未決的問題：我們如何對其進行自動化測試？ 我們如何確保網站佈局保持響應並在各種分辨率的各種設備上正確顯示？再加上動態內容、國際化和本地化要求帶來的複雜性，這成為一個真正的挑戰。

在本文中，我將引導您了解一種有趣的新佈局測試技術。使用 Galen 框架，我將提供一個詳細的教程，用於編寫有意義的通用佈局測試，可以在任何瀏覽器和任何設備上執行，同時用作設計文檔中的單一事實來源。

關於 SmashingMag 的進一步閱讀：

用於響應式界面設計的視覺測試驅動開發
應用程序、遊戲和移動網絡測試自動化的基礎知識
用於 React Native 應用程序的各種測試自動化框架

我還將展示我是如何為我們的分類網站 Marktplaats 上的消息傳遞頁面提出優化測試的。我們將學習如何用我們自己的語言擴展 Galen 的語法，如何改進測試代碼以及如何將佈局測試程序變成藝術。

跳躍後更多！繼續往下看↓

蓋倫框架簡介

一年前的“響應式界面設計的可視化測試驅動開發”中介紹了 Galen 框架。當時，它的語法是有限的。自那以後，它有了很大的改進，並獲得了許多新功能，我們將在這裡進行介紹。

如果您不熟悉 Galen Framework，它是一個用於響應式和跨瀏覽器佈局測試和功能測試的工具，具有自己的測試語言，名為 Galen Specs。它基於 Selenium WebDriver，還具有豐富的 JavaScript API，可讓您直接使用 WebDriver。因為您可以控制 WebDriver，所以您可以在任何瀏覽器、雲端（SauceLabs、BrowserStack、PerfectoMobile 等）或使用 Appium 的真實移動設備上運行測試。

安裝和執行

設置 Galen 框架很容易。只需執行以下命令即可通過 npm 安裝它：

 npm install -g galenframework-cli

如果您不使用 npm，只需下載最新的 Galen 框架存檔，解壓縮包並按照安裝說明進行操作。

安裝後，Galen Framework 可以通過多種方式啟動。例如，您可以使用check命令啟動單個頁面的快速測試。對於此命令，您需要提供一個帶有佈局驗證的.gspec文件，然後您可以像這樣調用它：

 galen check loginPage.gspec --url https://example.com --size 1024x768 --include desktop --htmlreport reports

此命令將啟動瀏覽器，打開指定的 URL，將瀏覽器窗口大小調整為 1024 × 768 像素，並執行loginPage.gspec文件中聲明的所有驗證。結果，您將獲得一份詳細的 HTML 報告。

管理測試套件

在現實世界中，實際的 Web 應用程序並不純粹由靜態頁面組成。很多時候，您必須執行一些操作才能到達您要檢查的地方。在這種情況下，Galen 提供了 JavaScript 測試套件和 GalenPages JavaScript API 來實現頁面對像模型。下面是一個 JavaScript Galen 測試的簡單示例：

 test("Home page", function() { var driver = createDriver("https://galenframework.com", "1024x768"); checkLayout(driver, "homePage.gspec", ["desktop"]); });

這是一個登錄頁面的頁面對像模型的實現，取自一個真實的項目。

 WelcomePage = $page("Welcome page", { loginButton: "#welcome-page .button-login" }); LoginPage = $page("Login page", { username: "input[name='login.username']", password: "input[name='login.password']", loginButton: "button.button-login" loginAs: loggedFunction ("Log in as ${_1.username} with password ${_1.password}", function(user) { this.username.typeText(user.username); this.password.typeText(user.password); this.loginButton.click(); }) }); test("Login page", function() { var driver = createDriver("https://testapp.galenframework.com", "1024x768"); var welcomePage = new WelcomePage(driver).waitForIt(); welcomePage.loginButton.click(); new LoginPage(driver).waitForIt(); checkLayout(driver, "loginPage.gspec", ["desktop"]); });

對於高級用法，我建議您查看 Galen Bootstrap 項目。它是專門為 Galen 構建的 JavaScript 擴展。它為 UI 測試提供了一些額外的功能，並為配置瀏覽器和執行複雜的測試套件提供了一種更簡單的方法。

簡單佈局測試

讓我首先在 Galen 框架中介紹一個簡單的佈局測試。然後，我將繼續討論高級用例並演示如何擴展 Galen Specs 語法。為此，我們將查看帶有圖標和標題的標題：

在 HTML 代碼中，它可能看起來像這樣：

 <body> <!-- … --> <div> <img class="header-logo" src="/imgs/header-logo.png"/> <h1>My Blog</h1> </div> <!-- … --> </body>

Galen 佈局測試的最簡單形式如下所示。首先，我們必須使用 CSS 選擇器聲明對象。

 @objects header #header icon #header img caption #header h1

然後，我們用有意義的名稱聲明一個測試部分，並將我們所有的驗證放在它下面。

 = Icon and Caption = icon: left-of caption 10 to 15px width 32px height 32px inside header 10px top caption: aligned horizontally all header inside header

在這裡，我們測試了兩個標題元素：圖標和標題。圖標和標題元素下列出的所有驗證實際上都是標準的 Galen Specs。這些規範是您可以組裝自己的佈局測試解決方案的基本構建塊。每個規範都會驗證單個屬性（例如寬度、高度、文本）、相對定位（例如內部、左側、上方）或屏幕截圖中的像素（例如配色方案、圖像）。

使用 forEach 循環測試多個元素

前面的示例演示了一個簡單的場景。讓我們看看如何處理更複雜的情況：水平菜單。首先，讓我們嘗試一種簡單的佈局測試技術。

首先匹配頁面上的多個元素。通過以下代碼，我們告訴 Galen 搜索與#menu ul li CSS 選擇器匹配的元素。

 @objects menu #menu item-* ul li

稍後，我們可以使用menu.item-1和menu.item-2等名稱引用這些項目，並使用@forEach循環遍歷所有菜單項。

 = Menu = menu.item-1: inside menu 0px top left bottom @forEach [menu.item-*] as menuItem, next as nextItem ${menuItem}: left-of ${nextItem} 0px aligned horizontally all ${nextItem}

如您所見，即使實際檢查沒有那麼複雜，代碼已經變得不那麼直觀了。想像一下，如果我們的測試中有更多類似的代碼。在某些時候，它會變成一個無法維護的爛攤子。應該有辦法改進它。

重新思考佈局測試

如果您考慮前面的示例，似乎我們可以用一兩句話來表達佈局。例如，我們可以這樣說，“所有菜單項都應該水平對齊，中間沒有邊距。第一個菜單項應該位於菜單的左側，沒有邊距。” 因為我們已經制定了句子來解釋我們想要的佈局，為什麼我們不能在我們的代碼中使用它們呢？想像一下，如果我們可以這樣寫代碼：

 = Menu = |first menu.item-* is in top left corner of menu |menu.item-* are aligned horizontally next to each other

事實上，這是從我的項目中復製而來的真實工作代碼。在最後兩行（從管道|開始）中，我們調用了自定義函數，這些函數通過解析這兩個語句來收集它們的參數。當然，上面的示例不會按原樣工作。為了讓它編譯，我們需要為這兩個語句實現處理程序。我們稍後會回到這個實現。

上面例子的關鍵點是佈局測試已經從對象驅動轉向表達式驅動測試。從這樣一個小例子中可能並不明顯，但在更大的範圍內肯定是顯而易見的。那麼，為什麼這很重要？簡短的回答是，這會改變我們的思維方式並影響我們設計軟件和為其編寫測試的方式。

使用這種技術，我們不會將我們的頁面視為一堆具有特定關係的對象。我們不測試單個元素的 CSS 屬性。我們避免編寫複雜的非平凡代碼。相反，我們試圖考慮常見的佈局模式和有意義的陳述。我們不是單獨測試菜單項 1、菜單項 2 等，而是應用以下通用語句：

可在其他元素上重現；
不包含硬編碼的像素值；
應用於抽象而非具體對象；
最後但並非最不重要的一點是，當我們閱讀它們時實際上是有意義的。

這個怎麼運作

讓我用這個簡單的例子來解釋自定義佈局表達式的機制：

在這個例子中，我們應該檢查按鈕是否拉伸到面板，左側或右側沒有邊距。如果沒有自定義規則，我們可以通過不同的方式來處理它，但我更喜歡以下解決方案：

 button: inside some_panel 0px left right

上面的代碼讓我們可以靈活地在邊上聲明自定義邊距，並且它還隱式測試按鈕是否完全包含在面板中。缺點是它的可讀性不是很好，這就是為什麼我要把這個驗證放在表達式button stretches to some_panel 。為了讓它起作用，我們需要編寫一個這樣的自定義規則：

 @rule %{elementName} stretches to %{parentName} ${elementName}: inside ${parentName} 0px left right

而已。現在我們只需一行就可以將它放入我們的測試中：

 | button stretches to some_panel

如您所見，此規則採用兩個參數： elementName和parentName 。這使我們也可以將其應用於其他元素。只需替換這兩個對象的名稱即可。

 | login_panel stretches to main_container | header stretches to screen | footer stretches to screen # etc.

實現你自己的測試語言

讓我們回到水平菜單佈局表達式的初始示例。

 = Menu = | first menu.item-* is in top left corner of menu | menu.item-* are aligned horizontally next to each other

我們可以通過以下方式實現第一條規則：

 @rule first %{itemPattern} is in %{cornerSides} corner of %{parentElement} @if ${count(itemPattern) > 0} ${first(itemPattern).name}: inside ${parentElement} 0px ${cornerSides}

在我們的示例中使用時，它將按如下方式解析參數：

itemPattern = menu.item-*
cornerSides = top left
parentElement = menu

因為我們已經完成了第一個表達式，我們可以移動到下一個表達式。在第二個表達式中，我們應該測試所有菜單項的水平對齊方式。我建議三個簡單的步驟：

查找所有菜單項。
遍歷所有這些直到倒數第二個元素。
檢查元素n是否位於元素n+1的左側，並且它們的頂部和底部邊緣對齊。

為了讓它工作，我們需要一個@forEach循環和規範left-of和aligned 。幸運的是，在 Galen 中，您可以在循環中引用上一個或下一個項目。如果您聲明了對下一個元素的引用，它只會迭代到倒數第二個元素，這正是我們所需要的。

 @rule %{itemPattern} are aligned horizontally next to each other @forEach [${itemPattern}] as item, next as nextItem ${item}: left-of ${nextItem} 0px aligned horizontally all ${nextItem}

您可能會問，如果我們必須在測試中指定邊距（例如~ 20px或10 to 20px ）怎麼辦？然後，我建議實施單獨的規則或擴展現有規則以支持%{margin}參數。

 @rule %{itemPattern} are aligned horizontally next to each other with %{margin} margin @forEach [${itemPattern}] as item, next as nextItem ${item}: left-of ${nextItem} ${margin} aligned horizontally all ${nextItem}

而已！我們創建了一個通用表達式來幫助我們驗證水平菜單。然而，由於它的靈活性，我們可以做的遠不止這些。我們可以使用它來測試頁面上的任何其他元素。我們甚至可以用它來測試兩個按鈕的對齊情況：

 | menu.item-* are aligned horizontally next to each other with 0px margin | submit_button, cancel_button are aligned horizontally next to each other with 20px margin

您可能會注意到，在這兩個示例中，我們以兩種不同的方式聲明了第一個參數。在第一個表達式中，第一個參數是“menu.item-*” ，而在第二個表達式中，它被聲明為“submit_button, cancel_button” 。這是可能的，因為@forEach循環允許我們使用逗號分隔的對象列表和星號運算符。但是我們還沒有完成重構。我們可以進一步改進代碼並使其更具可讀性。如果我們為菜單項和登錄表單按鈕創建組，我們可以完成這樣的事情：

 @groups menu_items menu_item-* login_form_buttons submit_button, cancel_button = Testing login page = | &menu_items are aligned horizontally next to each other with 0px margin | &login_form_buttons are aligned horizontally next to each other with 20px margin

在這種情況下，我們必須使用&符號，它代表組聲明。這已經是一個很好的測試了。首先，它可以正常工作，我們能夠測試我們需要的東西。此外，代碼清晰易讀。如果另一個人要問你登錄頁面應該是什麼樣子，設計要求是什麼，你可以告訴他們看測試。

如您所見，為複雜的佈局模式實現自定義表達式並不是什麼大問題。一開始可能很有挑戰性，但它仍然類似於某種創造性活動。

動態邊距

讓我們看看您有時會在各種網站上找到的另一種罕見的佈局模式。如果我們想測試元素之間的距離相等怎麼辦？讓我們嘗試為此實現另一個規則，但這次使用 JavaScript 實現。我提出這樣的說法： “box_item-* are aligned horizontally next to each other with equal distance” 。這會有點棘手，因為我們不知道元素之間的邊距，我們不能只硬編碼像素值。因此，我們要做的第一件事就是檢索第一個和最後一個元素之間的實際邊距。

一旦我們獲得該邊距，我們就可以在@forEach循環中聲明它，類似於我們之前所做的。我建議使用 JavaScript API 來實現此規則，因為所需的邏輯比我們之前的所有示例都複雜一些。讓我們創建一個名為my-rules.js的文件並輸入以下代碼：

 rule("%{objectPattern} are aligned horizontally next to each other with equal margin", function (objectName, parameters) { var allItems = findAll(parameters.objectPattern), distance = Math.round(Math.abs(allItems[1].left() - allItems[0].right())), expectedMargin = (distance - 1) + " to " + (distance + 1) + "px"; if (allItems.length > 0) { for (var i = 0; i < allItems.length - 1; i += 1) { var nextElementName = allItems[i + 1].name; this.addObjectSpecs(allItems[i].name, [ "aligned horizontally all " + nextElementName, "left-of " + nextElementName + " " + expectedMargin ]); } } });

在我們的測試代碼中，我們將這樣使用它：

 @script my-rules.js # … = Boxes = | box_item-* are aligned horizontally next to each other with equal distance

如您所見，在 Galen Framework 中，我們在實現規則時可以在兩種語言之間進行選擇：Galen Specs 和 JavaScript。對於簡單的表達式，Galen Specs 更容易使用，但對於復雜的表達式，我總是選擇 JavaScript。如果您想了解有關 JavaScript 規則的更多信息，請參閱文檔。

蓋倫特輯

玩夠了各種佈局模式後，我意識到所有這些 Galen 規則都可以輕鬆應用於任何其他測試項目。這給了我一個想法，將最常見的佈局表達式編譯到他們自己的庫中。這就是我創建 Galen Extras 項目的原因。以下是該庫功能的一些示例：

 | header.icon should be squared | amount of &menu_items should be > 3 | &menu_items are aligned horizontally next to each other | &list_items are aligned vertically above each other with equal distance | every &menu_item is inside menu 0px top and has width > 50px | first &menu_item is inside menu 0px top left | &menu_items are rendered in 2 column table | &menu_items are rendered in 2 column table, with 0 to 1px vertical and 10px horizontal margin | &login_form_elements sides are vertically inside content_container with 20px margin login_panel: | located on the left side of panel and takes 70 % of its width # etc …

Galen Extras 庫包含許多您在網站上常見的佈局模式，我會在發現有用的模式後立即對其進行更新。一旦建立了這個庫，我決定在一個真正的測試項目中嘗試它。

測試消息應用程序

目前，我在 Marktplaats 擔任軟件工程師。在某個時候，我決定將我獲得的所有經驗應用到一個真實的項目中。我需要測試我們網站上的消息傳遞頁面。這是它的樣子：

老實說，對這些頁面實施測試對我來說總是有點嚇人，尤其是佈局測試。但是有了 Galen Extras 庫，它實際上運行得非常順利，很快我就可以想出這段代碼：

 @import ../selected-conversation.gspec @groups (message, messages) messenger.message-* first_two_messages messenger.message-1,messenger.message-2 first_message messenger.message-1 second_message messenger.message-2 third_message messenger.message-3 (message_date_label, message_date_labels) messenger.date_label-* first_date_label messenger.date_label-1 second_date_label messenger.date_label-2 = Messages panel = = Messages and Date labels = |amount of visible &message_date_labels should be 1 |first &message_date_label has text is "17 november 2015" |amount of visible &messages should be 3 |&first_two_messages should be located at the left inside messenger with ~ 20px margin |&third_message should be located at the right inside messenger with ~ 20px margin |&messages are placed above each other with 10 to 15px margin |text of all &messages should be ["Hi there!", "I want to buy something", "Hello! Sure, it's gonna be 100 euros"] = Styling = |&first_two_messages should be styled as others message |&third_message should be styled as own message

提取像素範圍

測試看起來不錯：它緊湊且可讀，但仍遠非完美。我真的不喜歡所有這些邊距定義（ ~ 20px ， 10 to 15px ）。其中一些是重複的，很難理解它們各自代表什麼。這就是為什麼我決定將每個邊距隱藏在一個有意義的變量後面。

 # ... @set messages_side_margin ~ 20px messages_vertical_margin 10 to 15px = Messages panel = = Messages and Date labels = |amount of visible &message_date_labels should be 1 |first &message_date_label has text is "17 november 2015" |amount of visible &messages should be 3 |&first_two_messages should be located at the left inside messenger with ${messages_side_margin} margin |&third_message should be located at the right inside messenger with ${messages_side_margin} margin |&messages are placed above each other with ${messages_vertical_margin} margin # ...

如您所見，我已將邊距移至messages_vertical_margin和messages_side_margin 。我還聲明了一個minimal邊距，範圍在 0 到 1 像素之間。

 # ... @set minimal 0 to 1px = Conversations Panel = | &conversations are aligned above each other with ${minimal} margin # ...

基於圖像的驗證和自定義表達式

在介紹了頁面上所有主要元素的位置之後，我決定還測試樣式。我想驗證每條消息是否具有特定於用戶角色的背景顏色。當用戶登錄時，消息將具有淺藍色背景。其他用戶的消息將具有白色背景。如果未發送消息，則錯誤警報將具有粉紅色背景。以下是幫助我驗證這些樣式的規則：

 @set OWN_MESSAGE_COLOR #E1E8F5 OTHERS_MESSAGE_COLOR white ERROR_MESSAGE_COLOR #FFE6E6 @rule %{item} should be styled as %{style} message ${item}: @if ${style === "own"} color-scheme > 60% ${OWN_MESSAGE_COLOR}, 0.2 to 20 % ${MAJOR_TEXT_MESSAGE_COLOR} @elseif ${style === "error"} color-scheme > 60% ${ERROR_MESSAGE_COLOR}, 0.2 to 20 % ${MAJOR_TEXT_MESSAGE_COLOR} @else color-scheme > 60% ${OTHERS_MESSAGE_COLOR}, 0.2 to 20 % ${MAJOR_TEXT_MESSAGE_COLOR}

color-scheme規範驗證元素內顏色的比例分佈。它裁剪頁面的屏幕截圖並分析顏色分佈。因此，要檢查元素的背景顏色，我們只需檢查其分佈是否大於總顏色範圍的 60%。在測試中，這條規則的調用如下：

 = Styling = |&first_two_messages should be styled as others message |&third_message should be styled as own message

配置測試套件

消息傳遞應用程序是與 RESTful 消息傳遞 API 一起使用的動態應用程序。因此，要測試它在所有不同狀態下的佈局，我們必須準備測試數據。我決定模擬 Messaging API，以便能夠在測試套件中配置我的所有測試消息。這是我的測試套件的一個片段，它顯示了我們的測試是如何構建的。

 // ... testOnAllDevices("Unselected 2 conversations", "/", function (driver, device) { mock.onGetMyConversationsReturn(sampleConversations); refresh(driver); new MessageAppPage(driver).waitForIt(); checkLayout(driver, "specs/tests/unselected-conversations.gspec", device.tags); }); testOnAllDevices("When clicking a conversation it should reveal messages", "/", function (driver, device) { mock.onGetMyConversationsReturn(sampleConversations); mock.onGetSingleConversationReturn(sampleMessages); refresh(driver); var page = new MessageAppPage(driver).waitForIt(); page.clickFirstConversation(); checkLayout({ driver: driver, spec: "specs/tests/three-simple-messages-test.gspec", tags: device.tags, vars: { expectedTextProvider: textProvider({ "messenger.message-1": "Hi there!\n11:02", "messenger.message-2": "I want to buy something\n12:02", "messenger.message-3": "Hello! Sure, it's gonna be 100 euros\n13:02" }) } }); }); // ...

捕捉錯誤

實現這些簡單的表達式很快就會得到回報。讓我們來看看我們可以用我們的測試套件捕獲什麼樣的錯誤。

造型問題

這是一個示例，說明當我們的 CSS 代碼庫出現問題時，所有消息都以相同的背景呈現。

如果將此屏幕截圖與原始屏幕截圖進行比較，您會注意到最後一條消息具有白色背景，而它應該是淺藍色的。讓我們看看 Galen 是如何報告這個問題的：

對於突出顯示的對象，它color #e1e8f5 on “messenger.message-3” is 0% but it should be greater than 60% 。老實說，這個錯誤信息看起來不是很清楚，但是因為這個檢查是根據自定義規則生成的，所以我們總是可以在報告分支中查找它的原始名稱：

如果向上滾動，您會看到原始語句&third_message should be styled as own message 。這是使用自定義表達式的另一個好處：它們可以幫助您理解失敗並很好地描述所有這些生成的驗證。

定位問題

這是另一個由於元素對齊不正確而導致佈局出錯的示例。在下面的屏幕截圖中，您可以看到最後一條消息位於消息視口的左側，而不是右側。

讓我們再看一下帶有錯誤消息的屏幕截圖：

屏幕截圖突出顯示了消息傳遞容器和最後一個消息元素。與此同時，它顯示以下錯誤消息： “messenger.message-3” is 285px right which is not in range of 22 to 28px 。 Web 開發人員可能不清楚為什麼右側需要 22 到 28 像素的邊距。同樣，您必須在報告分支中查找驗證語句：

該檢查的原始語句是&third_message should be located at the right inside messenger with ~ 25px margin 。這更有意義。而且，其他前端工程師即使沒有寫過測試，也會看懂這份測試報告。

佈局測試指南

考慮到所有這些不同的實驗，我決定將所有的學習形式化為通用佈局測試指南。以下是簡化測試程序的步驟的快速清單。

識別設計中的佈局模式。
概括驗證語句。嘗試將大多數驗證壓縮為單個句子。
組件化！將重複元素的測試轉移到專用組件中總是更好。
為部分、規則和對象使用有意義的名稱。
避免像素。嘗試用有意義的變量替換像素值（無論是精確值還是范圍）。
調整您網站的代碼，使其更易於測試。這將幫助您構建和維護您的生產和測試代碼。

救援驗收標準

我經常會收到這樣的問題，“那麼佈局測試應該有多詳細？我們應該具體測試什麼？” 很難給出一個普遍的答案。問題是當測試的覆蓋率很小時，你會錯過錯誤。另一方面，如果您的測試過於詳細，您可能會得到很多誤報，並且將來您可能會迷失在測試維護中。所以，有一個權衡。但我確實為自己找到了一個通用的指導方針。如果您將工作拆分為更小的用戶故事，那麼以驗收標準的形式構建頁面設計會變得更容易。最後，您可能會將這個驗收標準正確地放入您的測試代碼中。例如，其中一些語句可以以自定義規則的形式定義，如前面所有代碼示例所示。驗收標準的一個很好的例子是這樣的：

彈出窗口應在屏幕上垂直和水平居中。
它們應該是 400 像素寬。
按鈕應水平對齊。
等等

一旦你用簡單的句子描述了設計，就可以更容易地將它們轉換為可重用的語句並組織你的測試代碼。

結論

如您所見，這樣的練習可以幫助您構建設計並發現可以跨多個頁面組件共享的一般佈局模式。即使頁面很複雜並且包含很多元素，您也總能找到一種方法在佈局表達式中對它們進行分組。通過這種方法，佈局測試更多地成為測試驅動開發的工具，幫助您逐步設計、實施和交付軟件，這在敏捷環境中特別有用。

資源

蓋倫框架（官網）
蓋倫框架，GitHub
Galen Extras（庫），GitHub
蓋倫引導，GitHub
“蓋倫框架教程”，YouTube