Behavior-Driven Development は、テストを誰もが読み書きできるようにすることで、チームのソフトウェア品質に対する考え方を根本的に変えました。BDD テストに Cucumber を使用するスキルは、ビジネス要件と技術的な実装の間のギャップを埋め、実際に実行される「生きたドキュメント」を作成します。もし、書いた瞬間に古くなってしまうテストケースに苦労しているなら、このガイドがより良い方法を示します。
Cucumber と BDD とは？
Cucumber は、平易な言葉で書かれた自動テストを実行するオープンソースツールです。これは Behavior-Driven Development (BDD) を実装しており、開発者、テスター、ビジネス関係者が具体的な例を用いてソフトウェアの動作を定義するために協力する手法です。
BDD は、「どのようにテストすべきか？」ではなく「システムは何をすべきか？」という一つの問いに焦点を当てます。その結果、誤解を解消し、仕様と実行可能な検証の両方として機能するテストを作成する共通言語が生まれます。
Cucumber は Gherkin 構文で書かれたシナリオを含む .feature ファイルを読み込み、ステップ定義（実際の自動化を実行するコード）に対してそれらを実行します。この分離により、ビジネス関係者はコードを読むことなくテストシナリオを確認でき、開発者は技術的な詳細を別途実装できます。
JavaScript 向け Cucumber のインストール
Node.js プロジェクトに Cucumber を設定するには、いくつかのコマンドを実行するだけです。
前提条件:
- Node.js
- NPM
- ログイン機能を持つ API プロジェクト（このチュートリアルでは Cucumber のインストールと Gherkin テストのみを扱います）。
# 新しいプロジェクトディレクトリを作成
mkdir cucumber-bdd-demo && cd cucumber-bdd-demo
# npm を初期化
npm init -y
# Cucumber とテスト関連の依存関係をインストール
npm install --save-dev @cucumber/cucumber chai axios
package.json にはテストスクリプトが含まれている必要があります。
{
"scripts": {
"test": "cucumber-js"
}
}
このディレクトリ構造を作成してください。
project/
├── features/
│ └── user-management.feature
├── step-definitions/
│ └── user-steps.js
├── package.json
└── cucumber.json
実践ガイド：初めての BDD テストの書き方
BDD テストに Cucumber を使用する方法 を実践するために、ユーザー管理 API のテストを作成してみましょう。
ステップ 1: Feature ファイルを作成する
features/user-management.feature を作成します。
Feature: User Management API
As an API client
I want to manage users
So that I can integrate user functionality into my application
Scenario: Create a new user successfully
Given I have a valid user payload
When I send a POST request to "/api/users"
Then the response status should be 201
And the response should contain a user ID
Scenario: Attempt to create user with invalid email
Given I have a user payload with invalid email
When I send a POST request to "/api/users"
Then the response status should be 400
And the response should contain "Invalid email format"
ステップ 2: ステップ定義を実装する
step-definitions/user-steps.js を作成します。
const { Given, When, Then } = require('@cucumber/cucumber');
const { expect } = require('chai');
const axios = require('axios');
let requestPayload;
let response;
Given('I have a valid user payload', function() {
requestPayload = {
name: 'Test User',
email: 'test@example.com',
password: 'ValidPass123'
};
});
Given('I have a user payload with invalid email', function() {
requestPayload = {
name: 'Test User',
email: 'invalid-email',
password: 'ValidPass123'
};
});
When('I send a POST request to {string}', async function(endpoint) {
try {
response = await axios.post(`http://localhost:3000${endpoint}`, requestPayload);
} catch (error) {
response = error.response;
}
});
Then('the response status should be {int}', function(statusCode) {
expect(response.status).to.equal(statusCode);
});
Then('the response should contain a user ID', function() {
expect(response.data).to.have.property('userId');
expect(response.data.userId).to.match(/^[0-9a-fA-F]{24}$/);
});
Then('the response should contain {string}', function(message) {
expect(response.data.message).to.include(message);
});
ステップ 3: cucumber.json ファイルを編集する
プロジェクトのルートディレクトリに "cucumber.json" ファイルを作成し、以下のコードを追加します。
{
"default": {
"formatOptions": {
"snippetInterface": "synchronous"
}
}
}ステップ 4: テストを実行する
以下のコマンドでテストを実行します。
npm test
Cucumber は、合格、未定義、失敗したステップを示す詳細な結果を出力します。
良い BDD シナリオを作成するためのルール
BDD テストに Cucumber を効果的に使用する方法 を学ぶには、以下の実証済みのルールに従う必要があります。
1. Given-When-Then 構造
すべてのシナリオには、次の 3 つの要素がこの順序で含まれている必要があります。
- Given: 事前条件を設定する
- When: アクションを記述する
- Then: 結果を検証する
2. 命令的ではなく宣言的に記述する
悪い例:
Given I open the browser
And I navigate to "/login"
And I type "test@example.com" in the email field
And I type "password" in the password field
And I click the login button
良い例:
Given I am on the login page
When I log in with valid credentials
Then I should see the dashboard
どのようにテストするかではなく、何をテストするかに焦点を当ててください。
3. 一つのシナリオ、一つの目的
各シナリオは、単一の動作をテストする必要があります。複合的なシナリオは失敗を隠し、デバッグを困難にします。
4. ビジネス言語を使用する
ビジネス関係者が理解できるシナリオを記述します。専門用語や実装の詳細を避けてください。
5. シナリオを独立させる
シナリオは互いに依存しないようにしてください。それぞれが独自のデータを設定し、後でクリーンアップする必要があります。
高度な Cucumber 機能: データテーブルとシナリオアウトライン
複雑な入力のためのデータテーブル
複数のデータポイントでテストする必要がある場合は、テーブルを使用します。
Scenario: Create users with different roles
Given I have the following user data:
| name | email | role |
| Alice | alice@example.com | admin |
| Bob | bob@example.com | user |
When I send a POST request to "/api/users"
Then all users should be created successfully
ステップ定義:
Given('I have the following user data:', function(dataTable) {
requestPayload = dataTable.hashes();
});
データ駆動テストのためのシナリオアウトライン
同じシナリオを異なるデータで実行したい場合は、アウトラインを使用します。
Scenario Outline: Login with various credentials
Given I am on the login page
When I enter "<email>" and "<password>"
Then I should see "<result>"
Examples:
| email | password | result |
| test@example.com | validPass | Dashboard |
| test@example.com | wrongPass | Invalid password|
| invalid@email.com | validPass | Invalid email |
これにより、3つの異なるテストシナリオが自動的に作成されます。
タグを使用したテストの整理
タグはシナリオを分類し、フィルタリングするのに役立ちます。
@smoke @regression
Scenario: User login
Given I am on the login page
When I log in with valid credentials
Then I should see the dashboard
@api @critical
Scenario: API health check
Given the API is running
When I request "/health"
Then the response status should be 200
特定のタグのみを実行します。
npm test -- --tags "@smoke"
BDD ワークフローにおける API テストで Apidog がどのように役立つか
Cucumber は振る舞いを定義するのに優れていますが、Apidog は API テストの作成と実行における面倒な作業を自動化し、BDD テストのための Cucumber をはるかに効率的にします。
AI を活用した API テストケースの生成
API 呼び出しのためのステップ定義を手動で書く代わりに、Apidog は OpenAPI 仕様から AI を使用してそれらを生成します。
# あなたの API 仕様
paths:
/api/users:
post:
requestBody:
content:
application/json:
schema:
type: object
properties:
name: string
email: string
responses:
'201':
description: User created
Apidog はテスト準備が整ったシナリオを自動的に作成します。
- ポジティブテスト: 有効なペイロード → 201 ステータス
- ネガティブテスト: 無効なメール → 400 ステータス
- 境界テスト: 必須フィールドの欠落 → 400 ステータス
よくある質問
Q1: Cucumber テストを書くためにプログラミングの知識は必要ですか？
A: Gherkin シナリオを書くのにコーディングは必要ありません。振る舞いについて明確に考えるだけです。ただし、ステップ定義を実装するには JavaScript (または他の言語) の知識が必要です。Apidog のようなツールは、ステップ定義コードを自動生成することでこの負担を軽減します。
Q2: Cucumber は従来のテストフレームワークとどう違うのですか？
A: 従来のフレームワーク (Jest、Mocha) は技術的な実装に焦点を当てています。Cucumber はビジネスの振る舞いに焦点を当てています。同じ Cucumber シナリオで、Gherkin テキストを変更することなく、Web UI テスト (Selenium)、API テスト (Axios)、モバイルテスト (Appium) を駆動できます。
Q3: Cucumber は API テストツールを置き換えられますか？
A: Cucumber はテスト構造を提供しますが、API 呼び出し (Axios、Supertest) を実行し、レスポンスを検証するためのツールは依然として必要です。Apidog は、API 実行レイヤーを処理することで Cucumber を補完し、Cucumber は BDD ワークフローを管理します。
Q4: 良い Cucumber シナリオとはどのようなものですか？
A: 良いシナリオは、独立しており、ビジネス言語を使用し、Given-When-Then 構造に従い、それぞれが単一の振る舞いをテストします。非技術的な関係者でも読めるようにし、システムが何をするか（how ではなく what）に焦点を当てるべきです。
Q5: Apidog は BDD テストで認証をどのように処理しますか？
A: Apidog は認証トークンを自動的に管理します。「Given I am authenticated」のようなステップを定義でき、Apidog の認証情報管理を使用して有効なトークンを取得することで、ステップ定義での手動によるトークン処理を排除できます。
結論
BDD テストに Cucumber を効果的に使用することは、技術チームとビジネスチームの間で共通理解を生み出すことで、開発プロセスを変革します。Gherkin 構文は明確さを強制し、シナリオとステップ定義の分離により、アプリケーションの進化に合わせてテストを保守しやすくなります。
真の力は、Cucumber を最新の自動化ツールと統合することから生まれます。Apidog は、API テストコードの作成という面倒な手作業を排除し、意味のある振る舞いの定義に集中できるようにすると同時に、実行を処理します。この組み合わせは、人間が読める仕様が「生きたドキュメント」として機能し、堅牢な自動テストが継続的に実行されるという、両方の長所をもたらします。
小さく始めてください。API エンドポイントを一つ選び、成功、失敗、エッジケースの3つのシナリオを作成します。ステップ定義を実装し、実行します。その結果をプロダクトオーナーに見せましょう。ビジネス要件がテストとして実行されるのを見れば、プロジェクト全体に BDD を展開することへの賛同を得られるでしょう。そのとき、BDD テストに Cucumber を使用することは、単なる技術的な実践ではなく、チーム全体の品質向上運動となるのです。