您可以將所有步驟定義放在一個檔案中,或放在多個檔案中。當您開始您的專案時,您的所有步驟定義可能都會放在一個檔案中。隨著專案的成長,您應該將步驟定義分割成不同檔案中有意義的群組。這將使您的專案更具邏輯性,也更容易維護。

Cucumber 如何找到您的功能和步驟定義

請注意,無論使用何種目錄結構,Cucumber 在執行測試時都會有效地將 features/ 目錄樹狀結構扁平化。這表示在 Cucumber 執行的目錄中,任何以 結尾的檔案都會被視為步驟定義。在同一個目錄中,Cucumber 會搜尋與該步驟定義相對應的 Feature。這可以是預設情況,也可以是使用 選項指定的位置。

步驟定義分組

從技術上來說,您如何命名步驟定義檔案,或將哪些步驟定義放入檔案中,並不重要。您可以擁有一個包含所有步驟定義的巨大檔案。但是,隨著專案的成長,該檔案可能會變得雜亂且難以維護。相反地,我們建議為每個領域概念建立一個單獨的 檔案。

一個好的經驗法則是為每個主要的 建立一個檔案。

例如,在履歷應用程式中,我們可能有

前三個檔案將定義與建立、讀取、更新和刪除各種相關的所有 GivenWhenThen 步驟定義。最後一個檔案將定義與登入和登出,以及特定使用者在系統中允許執行的不同動作相關的步驟定義。

如果您遵循此模式,也可以避免功能耦合的步驟定義反模式。

當然,如何分組步驟定義,完全取決於您和您的團隊。它們應該以對您的專案有意義的方式進行分組。

編寫步驟定義

請勿為您的情境中不存在的步驟編寫步驟定義。這些最終可能會變成未使用過的 雜物,之後需要清理。僅實作您實際需要的步驟定義。隨著專案的成長,您隨時可以重構您的程式碼。

避免重複

避免編寫相似的步驟定義,因為它們可能會導致混亂。雖然記錄您的步驟有幫助,但利用 輔助方法 來抽象化它們可以產生奇效。

例如,以下列步驟為例

    Given I go to the home page
    Given I check the about page of the website 
    Given I get the contact details

如果所有這些步驟都開啟各自的網頁,您可能會編寫多餘的步驟。雖然這些步驟的底層程式碼可能不同,但它們的行為本質上是相同的,也就是開啟首頁、關於或聯絡頁面

因此,您可以使用抽象的輔助方法將它們簡化為單一步驟

Given I go to the {} page

以及以下步驟定義

@Given("I go to the {string} page")
public void i_want_to_open_page(String webpage) {
  webpageFactory.openPage(webpage);
}
 Given("I go to the {string} page", function (webpage) {
   webpageFactory.openPage(webpage)
}
 Given 'I go to the {string} page' do |page|
   open_web_page page
 end
@Given("I go to the {string} page")
fun `I want to open page`(webpage: String) {
  webpageFactory.openPage(webpage)
}
s.Step(`^I go to the "([^"]*)" page$`, goToPage)

func goToPage(webpage string) error {
 return webpageFactory.Open(webpage)
}

您的步驟定義是實際程式碼的膠水(在此範例中,是一個決定要開啟哪個頁面的工廠方法)。它們也可以透過從一個步驟定義呼叫多個可重複使用的輔助方法來隱藏實作細節。

這在許多方面有所幫助

  • 提高可維護性。
  • 透過可重複使用的步驟提高可擴充性。
  • 更容易理解的測試。

您可以同樣的方式處理其他行為,例如驗證網頁、點擊按鈕等

此外,使用資料表為步驟提供輸入有助於提高可維護性和可理解性。

輔助方法

請始終記住,Cucumber 是對程式語言的 DSL 包裝器,您可以在步驟定義檔案中使用該語言的全部表達能力(但不能在功能檔案中使用)。另一方面,請不要忽略,步驟定義檔案中以這種方式呼叫的每個步驟都首先由 Gherkin 剖析,因此必須符合與功能檔案中使用的相同語法。

事實上,建議將步驟定義重構為輔助方法,以提高模組化和重複使用性。該方法可以與步驟定義位於同一個 檔案中。

這會讓稍後加入您專案的人更容易理解您的專案;這也讓您的專案更容易維護。

您可以協助我們改善此文件。編輯此頁面