作為軟件開發人員，我們都有最喜歡的工具來使我們成功。 許多人在上手時就很適合這份工作，但很快就不見了。 其他人則需要太多的設置和培訓才能“將腳趾浸入水中”，只是為了找出自己是否是正確的工具即可。

Cucumber JVM是一個測試框架，它增強了JUnit ，以便提供一種更輕松的方式來開始進行行為驅動開發（BDD）。 Gherkin語言 （Cucumber理解的語言）使軟件或質量工程師可以更輕松地用文字描述有關軟件應用程序中預期行為的方案。

對我而言，Cucumber允許表達哪些方案是自動化的，而無需“深入了解”并閱讀Java代碼。 這個簡短的博客描述了我為什么使用它，以及使用方法的提示，這些提示可能與大多數情況有所不同。

應用程序演變和需求變更

我認為，軟件需求規范更多是一種藝術形式。 如果我們可以詢問業務主題專家（SME），他們希望應用程序做什么，并讓他們抽象地提供所有必要的細節，那就太好了。 不幸的是，過去30多年來我從事的每個試圖預先收集需求的項目都不可避免地遇到了在開發過程中更改或誤解需求的情況，這使所有需求都尚未實現。

作為敏捷方法論的支持者，我相信最好的應用會不斷發展。 需求必須隨著時間而成形。 這個概念使僵化的項目經理甚至利益相關者發瘋。 “如果我不確切知道每個版本的要求，我該如何計劃三年？”

該主題可以提供其自己的博客，但現在讓我們簡單地期望在項目的所有階段都將發生需求變更。 能夠快速有效地做出反應是敏捷開發的全部意義所在。

因此，如果將12個月的項目中的5個月進行了改進，這是5個月的工作前提，那么如何確保對已編寫和測試的代碼所做的更改不會引起回歸問題？

為什么要使用黃瓜？

Cucumber和JUnit是使我能夠自動化應用程序的重要功能和使用場景的工具。 作為一個敏捷的開發人員，我必須期望我將重構代碼和設計以響應需求變化。 我編寫的單元測試和集成測試使我有信心，過去測試過的方案仍然有效。 這就是為什么我們要進行單元測試，但是仍然存在為什么要使用黃瓜的問題？

對我來說，當我領導的一個項目決定轉向JEE6，CDI和Interceptors時，Cucumber出現在了現場。 這些概念全部重用服務，并使用面向方面的編程將業務規則行為插入服務方法。 也就是說，我們決定使用Java攔截器來確保在每次服務方法調用開始之前都滿足業務規則。

那么，您到底如何測試這樣的概念？ 我不僅需要正確測試我的業務邏輯，還需要一個測試環境來模擬我的容器行為，以便對適當的集成測試進行編碼。

那時，實際上只有一套可以處理這種環境的工具：Cucumber和Arquillian。 Arquillian是Redhat的測試框架，可讓您“收縮包裝”可在測試容器中使用的可部署資源，從而使集成測試真正在容器中運行。 如何設置它并使其起作用是比我在這里要講的更高級的主題，但是從Arquillian Cucumber測試環境開始并不是要把腳趾浸入水中。 它更像是在漂著水母。

無論如何，該測試都需要我驅使我更多地研究Cucumber作為測試工具，這使我對BDD環境的多種可能性大開眼界。

現在就舉一個很好的例子。

到目前為止，這聽起來像是一個推銷活動，但讓我演示一下黃瓜測試的外觀。 讓我們以1040EZ表格為例。

如果我們正在為此編寫應用程序，則可能需要以下方案：

Feature: Form 1040EZScenario: Too much taxable interestGiven standard error messagesAnd Form line 1 contains $30,000.00And Form line 2 contains $1,501.00When Form is submittedThen an error message with id F1040EZ-1 is shown

因此，讓我們剖析這種情況。 Feature and Scenario語言只是用于幫助描述我們正在測試的內容以及特定情況的文本。 給定“何時”和“然后”語法是一種常見的按規范測試的術語，用于區分方案的不同部分。

• “給出”用于描述測試的設置。
• “何時”通常描述您正在測試的Java方法以及提供給它的參數。 我們的示例沒有參數。
• “然后”用于描述執行該方法的結果。 有時有消息； 其他時間則有預期的特定數據； 其他情況只是測試沒有破裂或更改。

如果您采用這種簡單的納稅表，則可能會發現許多其他情況，例如：

• 未指定所需值
• 矛盾的輸入
• 無效數據，例如負數或期望數字的文本
• 有效方案，例如退款和付款

在這個簡單的稅收示例中，有很多情況。 對于更復雜的形式，可能要測試數百種可能的方案。 測試的技巧是找到合適的，可管理的測試數量來編寫。

對于我們的簡單場景，Given-When-Then文本將作為“ .feature”文件存儲在Java代碼的資源中。 通常將所有功能文件一起存儲在一組模仿Java包結構的文件夾中。 實際上，為了簡化測試，您可以在與該文件夾結構匹配的程序包中創建Java類來測試此功能。

Java類在Cucumber中被稱為Steps文件，它定義了要為每個Step運行的Java代碼，它們簡單地是Given，When或Then。 使用@ Given，@ When和@Then批注的步驟與功能步驟匹配，這些批注具有用于進行匹配的正則表達式參數。

請參閱黃瓜文檔，以獲取更好的示例以及有關如何將它們組合在一起的更多詳細信息。

使用標準值編寫黃瓜腳本的技巧

如上面的示例所述，“給定”步驟設置了方案。 在我們的簡單場景中，第一個Given似乎隱藏了一些重要數據。 具體來說，該應用程序的標準消息是什么？ 更復雜的場景可能依賴于大量的預定義數據。

Cucumber提供了在表中列出給定數據的方法，因此您可以在每個“給定”步驟中非常明確地顯示相關的設置數據。 但是，這甚至會使最簡單的場景變得如此冗長，以至于沒有人會嘗試閱讀它們。

在我當前的項目中，我們已經進行了集成測試，以至于有數百行設置數據。 因此，我們大多數情況都始于：

Given STANDARD values for …..

“……” 替換為列出應該為標準對象提供哪些對象類別的關鍵字。 這使每個方案簡潔明了，但是如果非開發人員正在查看該方案，他們如何知道標準值是什么？

我們對此的解決方案是提供一個StandardObjects.feature文件。 該文件與所有其他文件一樣，以“給...提供標準值”開頭，但是每個方案都有一個“然后”步驟，該步驟顯示該標準對象的期望值表。

在上面的示例中，我們有：

Given standard error messages

使用這種STANDARD值功能方法，我們將重用Given并提供一個Then，如下所示：

Then standard error messages would include exactly the following:| id | message | | F1040EZ-1 |If taxable interest is greater than $1500, you cannot use 1040EZ | | F1040EZ-2 |Line X is required | | F1040EZ-3 |Value on line X is not valid |

將標準值期望值分離到一個單獨的功能可以使功能方案變得混亂，但仍可以看到標準值是什么。 但是，請注意，隨著標準值的更改或添加，必須更新功能文件。 但是我認為這是一件好事。

最后的想法

能夠快速有效地做出反應是敏捷開發的全部意義所在。 Cucumber是使我能夠自動執行應用程序的重要功能和使用場景的工具。 該博客描述了為什么我使用Cucumber來幫助實現該目標，以及如何使用它的技巧。 您也可以在此處查看有關此主題的另一個Keyhole博客。

需求的變更將在項目的所有階段發生，但是如果您擁有正確的工具，就可以避免痛苦。

翻譯自: https://www.javacodegeeks.com/2016/01/introducing-cucumber-java-standard-values.html

總結

以上是生活随笔為你收集整理的为Java + STANDARD值引入Cucumber的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。