วิธีใช้ Cucumber สำหรับการทดสอบแบบ BDD

Behavior-Driven Development (BDD) ได้เปลี่ยนแปลงวิธีการที่ทีมงานคิดเกี่ยวกับคุณภาพซอฟต์แวร์โดยทำให้การทดสอบสามารถอ่านได้สำหรับทุกคน! การใช้ Cucumber สำหรับการทดสอบ BDD เป็นทักษะที่เชื่อมช่องว่างระหว่างความต้องการทางธุรกิจและการนำไปใช้ทางเทคนิค สร้างเอกสารที่มีชีวิตที่สามารถเรียกใช้งานได้จริง หากคุณเคยประสบปัญหาเกี่ยวกับกรณีทดสอบที่ล้าสมัยทันทีที่เขียน คู่มือนี้จะแสดงวิธีที่ดีกว่าให้คุณ

Cucumber และ BDD คืออะไร?

Cucumber เป็นเครื่องมือโอเพนซอร์สที่ใช้รันการทดสอบอัตโนมัติซึ่งเขียนด้วยภาษาธรรมดา โดยจะนำ Behavior-Driven Development (BDD) มาใช้ ซึ่งเป็นระเบียบวิธีที่นักพัฒนา ผู้ทดสอบ และผู้มีส่วนได้ส่วนเสียทางธุรกิจทำงานร่วมกันเพื่อกำหนดพฤติกรรมของซอฟต์แวร์โดยใช้ตัวอย่างที่เป็นรูปธรรม

BDD มุ่งเน้นไปที่การตอบคำถามเดียวว่า "ระบบควรทำอะไร?" แทนที่จะเป็น "เราควรทดสอบอย่างไร?" ผลลัพธ์ที่ได้คือภาษาที่ใช้ร่วมกันซึ่งช่วยขจัดความเข้าใจผิดและสร้างการทดสอบที่ทำหน้าที่ทั้งเป็นข้อกำหนดและการตรวจสอบที่สามารถดำเนินการได้

Cucumber จะอ่านไฟล์ .feature ที่มีสถานการณ์การทดสอบที่เขียนด้วยไวยากรณ์ Gherkin และดำเนินการกับ step definitions ซึ่งเป็นโค้ดที่ทำการทำงานอัตโนมัติจริง การแยกส่วนนี้หมายความว่าผู้มีส่วนได้ส่วนเสียทางธุรกิจสามารถตรวจสอบสถานการณ์การทดสอบได้โดยไม่ต้องอ่านโค้ด ในขณะที่นักพัฒนาจะนำรายละเอียดทางเทคนิคไปใช้งานแยกต่างหาก

การติดตั้ง Cucumber สำหรับ JavaScript

การตั้งค่า Cucumber ในโปรเจกต์ Node.js ใช้เพียงไม่กี่คำสั่ง:

ข้อกำหนดเบื้องต้น:

• Node.js
• NPM
• โปรเจกต์ API ที่มีฟีเจอร์การเข้าสู่ระบบซึ่งเราจะทำการทดสอบ (บทช่วยสอนนี้จะครอบคลุมเฉพาะการติดตั้ง Cucumber และการทดสอบ Gherkin เท่านั้น)

# Create a new project directory
mkdir cucumber-bdd-demo && cd cucumber-bdd-demo

# Initialize npm
npm init -y

# Install Cucumber and testing dependencies
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 Test ครั้งแรกของคุณ

มาสร้างการทดสอบสำหรับ User Management API เพื่อสาธิต วิธีการใช้ Cucumber สำหรับการทดสอบ BDD ในทางปฏิบัติกัน

ขั้นตอนที่ 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

สร้างไฟล์ 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 Scenarios ที่ดี

การเรียนรู้ วิธีการใช้ Cucumber สำหรับการทดสอบ BDD อย่างมีประสิทธิภาพจำเป็นต้องปฏิบัติตามกฎที่ได้รับการพิสูจน์แล้วเหล่านี้:

1. โครงสร้าง Given-When-Then

ทุกสถานการณ์จะต้องมีสามส่วนนี้ตามลำดับ:

• 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: Data Tables และ Scenario Outlines

Data Tables สำหรับข้อมูลอินพุตที่ซับซ้อน

เมื่อคุณต้องการทดสอบด้วยข้อมูลหลายจุด ให้ใช้ตาราง:

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

Step definition:

Given('I have the following user data:', function(dataTable) {
  requestPayload = dataTable.hashes();
});

Scenario Outlines สำหรับการทดสอบที่ขับเคลื่อนด้วยข้อมูล

เมื่อคุณต้องการรันสถานการณ์เดียวกันด้วยข้อมูลที่แตกต่างกัน ให้ใช้ outlines:

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   |

สิ่งนี้สร้างสถานการณ์การทดสอบสามสถานการณ์แยกกันโดยอัตโนมัติ

การจัดระเบียบการทดสอบด้วยแท็ก

แท็กช่วยให้คุณจัดหมวดหมู่และกรองสถานการณ์ได้:

@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"

Apidog ช่วยในการทดสอบ API ในเวิร์กโฟลว์ BDD ได้อย่างไร

ในขณะที่ Cucumber มีความโดดเด่นในการกำหนดพฤติกรรม Apidog ก็ทำให้การสร้างและดำเนินการทดสอบ API เป็นไปโดยอัตโนมัติ ทำให้การใช้ Cucumber สำหรับการทดสอบ BDD มีประสิทธิภาพมากยิ่งขึ้น

การสร้างกรณีทดสอบ API ที่ขับเคลื่อนด้วย AI

แทนที่จะเขียน step definitions สำหรับการเรียก API ด้วยตนเอง Apidog จะสร้างสิ่งเหล่านี้จาก OpenAPI specification ของคุณโดยใช้ AI:

# Your API spec
paths:
  /api/users:
    post:
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                name: string
                email: string
      responses:
        '201':
          description: User created

Apidog จะสร้างสถานการณ์การทดสอบพร้อมใช้งานโดยอัตโนมัติ:

• การทดสอบแบบ Positive: Payload ที่ถูกต้อง → สถานะ 201
• การทดสอบแบบ Negative: อีเมลไม่ถูกต้อง → สถานะ 400
• การทดสอบขอบเขต (Boundary test): ไม่มีฟิลด์ที่จำเป็น → สถานะ 400

คำถามที่พบบ่อย

คำถามที่ 1: ฉันจำเป็นต้องรู้การเขียนโปรแกรมเพื่อเขียน Cucumber tests หรือไม่?

คำตอบ: การเขียนสถานการณ์ Gherkin ไม่จำเป็นต้องเขียนโค้ด เพียงแค่คิดอย่างชัดเจนเกี่ยวกับพฤติกรรม อย่างไรก็ตาม การใช้ step definitions ต้องมีความรู้ด้าน JavaScript (หรือภาษาอื่นๆ) เครื่องมืออย่าง Apidog ช่วยลดภาระนี้โดยการสร้างโค้ด step definition โดยอัตโนมัติ

คำถามที่ 2: Cucumber แตกต่างจากเฟรมเวิร์กการทดสอบแบบดั้งเดิมอย่างไร?

คำตอบ: เฟรมเวิร์กแบบดั้งเดิม (Jest, Mocha) มุ่งเน้นไปที่การนำไปใช้ทางเทคนิค ในขณะที่ Cucumber มุ่งเน้นไปที่พฤติกรรมทางธุรกิจ สถานการณ์ Cucumber เดียวกันสามารถขับเคลื่อนการทดสอบ UI บนเว็บ (Selenium), การทดสอบ API (Axios) หรือการทดสอบบนมือถือ (Appium) ได้โดยไม่ต้องเปลี่ยนข้อความ Gherkin

คำถามที่ 3: Cucumber สามารถแทนที่เครื่องมือทดสอบ API ได้หรือไม่?

คำตอบ: Cucumber มีโครงสร้างการทดสอบให้ แต่คุณยังคงต้องการเครื่องมือเพื่อเรียกใช้ API (Axios, Supertest) และตรวจสอบการตอบสนอง Apidog เติมเต็ม Cucumber โดยการจัดการเลเยอร์การเรียกใช้ API ในขณะที่ Cucumber จัดการเวิร์กโฟลว์ BDD

คำถามที่ 4: อะไรคือสิ่งที่ทำให้สถานการณ์ Cucumber เป็นสิ่งที่ดี?

คำตอบ: สถานการณ์ที่ดีต้องเป็นอิสระ ใช้ภาษานักธุรกิจ เป็นไปตามโครงสร้าง Given-When-Then และทดสอบพฤติกรรมเดียวในแต่ละครั้ง ควรเป็นสิ่งที่ผู้มีส่วนได้ส่วนเสียที่ไม่ใช่สายเทคนิคสามารถอ่านเข้าใจได้ และมุ่งเน้นไปที่สิ่งที่ระบบทำ ไม่ใช่วิธีการทำ

คำถามที่ 5: Apidog จัดการการยืนยันตัวตนในการทดสอบ BDD อย่างไร?

คำตอบ: Apidog จัดการโทเค็นการยืนยันตัวตนโดยอัตโนมัติ คุณสามารถกำหนดขั้นตอน "Given I am authenticated" ที่ใช้การจัดการข้อมูลประจำตัวของ Apidog เพื่อดึงโทเค็นที่ถูกต้อง ซึ่งช่วยลดการจัดการโทเค็นด้วยตนเองใน step definitions ของคุณ

สรุป

การใช้ Cucumber สำหรับการทดสอบ BDD จะเปลี่ยนกระบวนการพัฒนาของคุณได้อย่างมีประสิทธิภาพ โดยการสร้างความเข้าใจร่วมกันระหว่างทีมเทคนิคและทีมธุรกิจ ไวยากรณ์ Gherkin บังคับให้เกิดความชัดเจน ในขณะที่การแยกสถานการณ์และ step definitions ทำให้การทดสอบสามารถบำรุงรักษาได้เมื่อแอปพลิเคชันของคุณพัฒนาขึ้น

พลังที่แท้จริงมาจากการผสานรวม Cucumber เข้ากับเครื่องมืออัตโนมัติที่ทันสมัย Apidog ช่วยลดงานที่น่าเบื่อหน่ายในการเขียนโค้ดทดสอบ API ด้วยตนเอง ทำให้คุณสามารถมุ่งเน้นไปที่การกำหนดพฤติกรรมที่มีความหมาย ในขณะที่ Apidog จัดการการดำเนินการเอง การรวมกันนี้ให้สิ่งที่ดีที่สุดของทั้งสองโลก: ข้อกำหนดที่มนุษย์อ่านได้ซึ่งทำหน้าที่เป็นเอกสารที่มีชีวิต และการทดสอบอัตโนมัติที่แข็งแกร่งซึ่งทำงานได้อย่างต่อเนื่อง

เริ่มต้นจากเล็กๆ เลือก API endpoint หนึ่งจุด เขียนสามสถานการณ์: สำเร็จ, ล้มเหลว และกรณีขอบ (edge case) นำ step definitions ไปใช้งาน รันการทดสอบ แสดงผลลัพธ์ให้เจ้าของผลิตภัณฑ์ของคุณดู เมื่อพวกเขาเห็นข้อกำหนดทางธุรกิจถูกนำไปใช้เป็นการทดสอบ คุณก็จะได้รับการสนับสนุนในการขยาย BDD ไปทั่วทั้งโปรเจกต์ของคุณ นั่นคือเมื่อการใช้ Cucumber สำหรับการทดสอบ BDD หยุดเป็นเพียงการปฏิบัติทางเทคนิค และกลายเป็นการเคลื่อนไหวเพื่อคุณภาพทั้งทีม