すべてのステップ定義を1つのファイルに、または複数のファイルに記述できます。プロジェクトを開始したときは、すべてのステップ定義が1つのファイルに含まれている可能性があります。プロジェクトが大きくなるにつれて、ステップ定義を意味のあるグループに分割して、異なるファイルに配置する必要があります。これにより、プロジェクトがより論理的になり、保守が容易になります。
Cucumber がフィーチャとステップ定義を見つける方法
採用されているディレクトリ構造に関係なく、Cucumber はテストを実行するときに `features/` ディレクトリツリーを事実上フラット化することに注意してください。これは、Cucumber が実行されるディレクトリ内にある`.java``.kt``.js``.rb``.go`で終わるものはすべてステップ定義として扱われることを意味します。同じディレクトリ内で、Cucumber はそのステップ定義に対応する `Feature` を検索します。これは、デフォルトの場合、または関連関連関連`-r`関連オプションで指定された場所です。
ステップ定義のグループ化
技術的には、ステップ定義ファイルの名前、またはファイルに配置するステップ定義は問われません。すべてのステップ定義を含む巨大な1つのファイルを持つことも*できます*。ただし、プロジェクトが大きくなるにつれて、ファイルが乱雑になり、保守が困難になる可能性があります。代わりに、ドメインの概念ごとに個別の`*_steps.rb``StepDefinitions.java``StepDefinitions.kt``*_steps.js``*_steps.go`ファイルを作成することをお勧めします。
経験則として、主要なモデル/データベーステーブルドメインオブジェクトドメインオブジェクトドメインオブジェクトドメインオブジェクトごとに1つのファイルを作成することをお勧めします。
たとえば、履歴書アプリケーションでは、次のようなファイルがあります。
employee_steps.rb
education_steps.rb
experience_steps.rb
authentication_steps.rb
EmployeeStepDefinitions.java
EducationStepDefinitions.java
ExperienceStepDefinitions.java
AuthenticationStepDefinitions.java
EmployeeStepDefinitions.kt
EducationStepDefinitions.kt
ExperienceStepDefinitions.kt
AuthenticationStepDefinitions.kt
employee_steps.js
education_steps.js
experience_steps.js
authentication_steps.js
employee_steps.go
education_steps.go
experience_steps.go
authentication_steps.go
最初の3つのファイルは、さまざまなモデルタイプのオブジェクトタイプのオブジェクトタイプのオブジェクトの作成、読み取り、更新、削除に関連するすべての `Given`、`When`、および `Then` ステップ定義を定義します。最後のファイルは、ログインとログアウト、およびシステム内で特定のユーザーが実行できるさまざまな操作に関連するステップ定義を定義します。
このパターンに従うと、フィーチャ結合ステップ定義アンチパターンも回避できます。
もちろん、ステップ定義をどのようにグループ化かは、あなたとあなたのチーム次第です。*あなたの*プロジェクトにとって意味のある方法でグループ化する必要があります。
ステップ定義の記述
シナリオのいずれにも存在しないステップのステップ定義を記述しないでください。これらは、後でクリーンアップする必要がある未使用のクラストになる可能性があります。実際に必要なステップ定義のみを実装してください。プロジェクトが大きくなるにつれて、コードをリファクタリングすることができます。
重複の回避
類似したステップ定義を記述すると、混乱を招く可能性があるため、記述しないでください。ステップを文書化すると役立ちますが、抽象化するためにヘルパーメソッドを使用すると、非常に効果的です。
たとえば、次のステップについて考えてみましょう。
Given I go to the home page
Given I check the about page of the website
Given I get the contact details
これらのすべてのステップでそれぞれのWebページが開かれる場合、*冗長なステップ*を記述している可能性があります。これらのステップの基になるコードは異なる場合がありますが、それらの**動作**は本質的に同じです。つまり、*ホームページ、概要ページ、または連絡先ページを開く*ことです。
そのため、抽象ヘルパーメソッドを使用して、それらを1つのステップに減らすことができます。
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)
}
ステップ定義は、実際のコード(この例では、開くページを決定するファクトリメソッド)への接着剤です。また、1つのステップ定義から複数の再利用可能なヘルパーメソッドを呼び出すことで、実装の詳細を隠すためにも使用できます。
これは、いくつかの点で役立ちます。
- 保守性の向上。
- 再利用可能なステップによるスケーラビリティの向上。
- より理解しやすいテスト。
*Webページの検証、ボタンのクリックなど*、他の動作も同じ方法で処理できます。
ファクトリデザインパターンも参照することをお勧めします。ファクトリデザインパターンも参照することをお勧めします。ファクトリデザインパターンも参照することをお勧めします。また、ステップへの入力を提供するためにデータテーブルを使用すると、保守性と理解度が向上します。
ヘルパーメソッド
Cucumber はプログラミング言語の DSL ラッパーであり、その完全な表現力はステップ定義ファイル(*フィーチャファイルではない*)で引き続き使用できることに常に留意してください。一方、ステップ定義ファイルでそのように呼び出されるすべてのステップは、最初にGherkinによって解析されるため、フィーチャファイルで使用されるのと同じ構文に準拠する必要があることに注意してください。
実際、モジュール性と再利用性を高めるために、ステップ定義をヘルパーメソッドにリファクタリングすることをお勧めします。メソッドは、ステップ定義と同じ`.java``.kt``.js``.rb``.go`ファイルに配置できます。
これにより、後でプロジェクトに参加する人にとってプロジェクトがより理解しやすくなり、プロジェクトの保守も容易になります。