黃瓜特點:概述
已發表: 2022-04-20介紹
Gherkin 是一種仍在許多測試自動化框架中使用的語言。 有時是因為客戶要求我們使用它,有時是因為團隊決定這樣做。
老實說,這對我來說並不是一見鍾情。 我個人與 Gherkin 有一段相當長的旅程——從一開始喜歡它,到一段時間厭惡這種語言,然後又重新喜歡它。 在本文中,我將介紹最重要的 Cucumber 特性以及 Java 實現。
以下是本文介紹的所有 Cucumber 功能:
特徵 | 描述 |
---|---|
設想 | 簡單場景 |
情景大綱 | 要求用戶在“示例”部分提供測試數據 |
數據表 | 要求用戶提供測試步驟的測試數據 |
場景上下文 | 在測試步驟之間共享值 |
黃瓜數據類型 | 黃瓜處理的數據類型 |
黃瓜正則表達式 | 黃瓜場景中正則表達式的使用 |
黃瓜鉤 | 在測試場景中執行附加代碼 |
特徵文件
首先,什麼是特徵文件? 在技術領域,創建了一種非技術方法,以允許非技術人員在開發應用程序期間與團隊合作。 Gherkin 語言是作為 BDD 方法中的附加層創建的。 Gherkin 測試位於與代碼(Java、Kotlin、C# 等)粘合的所謂功能文件中。 通常 Gherkin 非常易於使用,並且需要最少的編程知識,但有些功能需要一些編碼。
讓我們從簡單的事情開始。
設想
這是 Cucumber 測試中最基本和最容易使用的示例:
特點:情景 背景:測試場景之前 鑑於我在步驟之前執行 @測試 場景:場景 鑑於我使用“場景 1”的參數化步驟
代碼塊 1. 場景
代碼塊 1. 包含一些需要解釋的內容:
- Feature :特徵文件的標題
- 背景:允許用戶在功能文件中定義的每個測試場景之前執行測試步驟的關鍵字
- @Test :告訴測試框架應該執行什麼測試場景的標籤。 “測試”由用戶定義。 我們可以使用例如“@SmokeTest”
- 場景:測試場景名稱
Gherkin 測試在每個測試步驟之前使用 [Given, When, Then, But] 關鍵字。 在我們唯一的測試步驟中,除了背景步驟,我們使用了一個參數,我們在其中傳遞了值“場景 1”。
現在,讓我們看看粘合的 Java 代碼是什麼樣的:
@Given("我在步驟之前執行") 公共無效 iExecuteBeforeStep() { //一些實現 } @Given("我使用 {string} 的參數化步驟") 公共無效 iUseParametrizedStepOf(字符串 p){ //一些實現 }
代碼塊2.場景的Java代碼實現
情景大綱
讓我們做一些更複雜的事情:
特徵:場景大綱 @測試 場景大綱:場景大綱 鑑於我使用“<parameter1>”和“<parameter2>”運行該步驟 例子: | 參數1 | 參數2 | | 參數1a | 參數2a | | 參數1b | 參數2b |
代碼塊 3. 場景大綱
這次我們將使用場景大綱,它允許我們使用不同的測試數據配置重複測試場景。 代碼塊 3. 包含一些需要解釋的內容:
- 示例:測試場景要使用的測試數據矩陣。 第一行是帶有參數名稱的標題。
和java實現:
@Given("我用 {string} 和 {string} 運行這一步") 公共無效 iRunStepWithAnd(字符串 p1,字符串 p2){ //一些實現 }
代碼塊 4. 場景大綱的 Java 實現
數據表
場景大綱非常有用,但是如果我們不想重複整個測試場景而只想重複一個測試步驟怎麼辦? Gherkin 有一種方法可以做到這一點,它被稱為“數據表”。
特徵:數據表 @測試 場景:數據表場景 鑑於我驗證該列包含預期值 | 列名 | 預期值 | | 一些列名 | 一些期望值 |
代碼塊 5. 數據表
帶有數據表的場景與場景大綱沒有太大區別。 唯一的問題是我們沒有在表格之前放置“示例”關鍵字。
Java 實現看起來比以前的情況要復雜一些:
@Given("我驗證該列是否包含預期值") 公共無效 iVerifyColumnValuesInTableUsingQueryFromFileOnSchema(DataTable dataTable) { List<Map<String, String>> data = dataTable.asMaps(); for (Map<String, String> 形式:數據) { String columnName = form.get("columnName"); String expectedResult = form.get("expectedValue"); //一些實現 } } }
代碼塊 6. 數據表的 Java 實現
為了訪問數據表中的數據,我們創建了一個“DataTable”類型的特殊變量 dataTable。 所有數據都將存儲在 List 變量中。
場景上下文
使用場景上下文,我們可以在步驟之間共享數據。 假設我們有一個兩步場景,我們希望將值“數據”從第 1 步傳遞到第 2 步(代碼塊 7)。
@測試 場景:場景上下文 鑑於我設置場景上下文值“數據” 鑑於我使用場景上下文值
代碼塊 7. 場景上下文

首先,我們需要構建一個名為 ScenarioContext 的特殊類,該類具有設置和獲取數據的場景上下文功能(代碼塊 8)。 我們的場景上下文是一個帶有鍵值對的 HashMap。 我們將通過它的鍵來識別值。
- scenarioContext() : 鍵值對的HashMap
- setContext() : 存儲場景上下文數據的鍵值方法
- getContext() : 獲取數據提供鍵的方法
公共類 ScenarioContext { 私有 Map<String, Object> 場景上下文; 公共場景上下文(){ 場景上下文 = 新的 HashMap<>(); } public void setContext(上下文鍵,對象值){ 場景上下文.put(key.toString(), value); } 公共對象getContext(上下文鍵){ 返回scenarioContext.get(key.toString()); } } 公共枚舉上下文{ ID; }
代碼塊 8. Scenario Context 類的 Java 實現
有了這個,我們可以使用已實現的方法。 然後在第 1 步中,我們在場景上下文中設置該值,在第 2 步中我們獲得該值(代碼塊 9)。
ScenarioContext 場景上下文 = new ScenarioContext(); @Given("我設置了場景上下文值 {string}") 公共無效iSetScenarioContextValue(字符串值){ 場景上下文.setContext(上下文.ID,值); } @Given("我使用場景上下文值") 公共無效 iUseScenarioContextValue() { String sharedValue = scenarioContext.getContext(Context.ID).toString(); }
代碼塊 9. 場景上下文步驟
黃瓜數據類型
Cucumber 處理有限數量的數據類型。 我們可以定義字符串、整數和浮點值,但對於布爾值,我們需要編寫一些變通方法。
@測試 場景:有變量的場景 鑑於我使用字符串“string”、int 1、float 1.1 和布爾值“false”
代碼塊 10. Cucumber 數據類型
Java 代碼看起來像這樣:
@Given("我使用字符串 {string}、int {int}、float {float} 和 boolean {string}") 公共無效 iUseStringIntFloatAndBoolean(字符串 var1,int var2,雙 var3,字符串 var4){ 布爾 f = Boolean.valueOf(var4); //一些代碼 }
代碼塊 11. Cucumber 數據類型的 Java 實現
黃瓜正則表達式
這是另一個經常使用的功能。 代碼塊 12 顯示了一個兩步場景,其區別僅在於使用不同的變量值(var1 和 var2)。 這實際上只是一步,在 Java 代碼(代碼塊 13)中,我們只定義了一種方法,但使用正則表達式和一個參數 var。
@測試 場景:正則表達式場景 鑑於我使用變量 var1 鑑於我使用變量 var2
代碼塊 12. Cucumber 中的正則表達式
@Given("^我使用變量 (.*)") 公共無效examTimeTableInSummerSeason(字符串變量){ 如果(var.equals(“var1”)){ //一些代碼 } 否則如果(var.equals(“var2”)){ //一些代碼 } }
代碼塊 13. Cucumber 正則表達式的 Java 實現
黃瓜鉤
最後但同樣重要的是:黃瓜鉤。
代碼塊 14 展示了 4 個最重要的鉤子:
- @Before :在每個測試場景之前執行代碼
- @After :在每個測試場景之後執行代碼
- @BeforeStep :在每個測試步驟之前執行代碼
- @AfterStep :在每個測試步驟之後執行代碼
@前 public void beforeScenario() { //一些代碼 } @後 公共無效 afterScenario() { //一些代碼 } @BeforeStep public void beforeStep() { //一些代碼 } @AfterStep 公共無效 afterStep() { //一些代碼 }
代碼塊 14. 黃瓜鉤
概括
我希望我說服了你在測試中使用 Gherkin。 這幾個功能將使您的測試更具可讀性,並且非技術人員更容易理解。 此外,對於新加入者來說,更容易理解業務邏輯並減少他們的入職時間。