รูปแบบ Gherkin

Updated:16 มีนาคม 2569Published:14 มีนาคม 2569

Gherkin記法 (สัญกรณ์ Gherkin) คือรูปแบบโครงสร้างที่ใช้อธิบายพฤติกรรมของซอฟต์แวร์ในลักษณะภาษาธรรมชาติ โดยแบ่งออกเป็น 3 ขั้นตอน ได้แก่ Given (เงื่อนไขเริ่มต้น), When (การกระทำ) และ Then (ผลลัพธ์) สัญกรณ์นี้ถูกใช้อย่างแพร่หลายในฐานะรูปแบบมาตรฐานของไฟล์ .feature ที่เครื่องมือทดสอบอัตโนมัติ Cucumber ใช้อ่านข้อมูล

ทำไมต้องใช้ Gherkin

ในหลายทีมพัฒนา นักพัฒนาจัดการเอกสารข้อกำหนดการทดสอบด้วยโค้ด ในขณะที่ฝ่ายธุรกิจจัดการด้วยเอกสารภาษาญี่ปุ่นหรือภาษาอังกฤษแยกจากกัน ทุกครั้งที่มีการเปลี่ยนแปลงข้อกำหนด จำเป็นต้องอัปเดตทั้งสองส่วน ทำให้เกิดความคลาดเคลื่อนสะสมขึ้นเรื่อยๆ

Gherkin notation แก้ปัญหานี้ด้วยแนวทางที่เรียกว่า "เอกสารข้อกำหนดที่สามารถรันได้" ไวยากรณ์ของมันใกล้เคียงกับภาษาธรรมชาติที่ผู้รับผิดชอบด้านธุรกิจสามารถอ่านได้ ในขณะเดียวกันก็สามารถรันเป็นการทดสอบอัตโนมัติได้โดยตรง เนื่องจากเอกสารข้อกำหนดและโค้ดทดสอบอยู่ในไฟล์เดียวกัน จึงยากที่จะเกิดความแตกต่างกันในเชิงโครงสร้าง

ไวยากรณ์พื้นฐาน

โครงสร้างทั่วไปของไฟล์ .feature มีดังนี้

gherkin

Feature: ユーザーログイン

  Scenario: 正しい認証情報でログインできる
    Given ログインページを表示している
    When メールアドレス "user@example.com" を入力する
    And パスワード "correct-password" を入力する
    And ログインボタンをクリックする
    Then ダッシュボードが表示される

Feature คือกลุ่มของฟีเจอร์หนึ่งหน่วย และ Scenario สอดคล้องกับ test case แต่ละรายการ สามารถเพิ่มเงื่อนไขได้ด้วย And / But และรองรับการ parameterize ด้วย Scenario Outline + ตาราง Examples

หนึ่งในจุดเด่นคือรองรับภาษาธรรมชาติมากกว่า 70 ภาษา รวมถึงภาษาญี่ปุ่น และสามารถ localize keyword ได้โดยตรง

ความสัมพันธ์กับ BDD

Gherkin notation กำเนิดขึ้นจาก practice ของ BDD (Behaviour-Driven Development) ใน BDD จะให้ความสำคัญกับการอธิบายว่า "ซอฟต์แวร์ควรทำอะไร" ในรูปแบบที่ผู้มีส่วนได้ส่วนเสียทุกฝ่ายสามารถแบ่งปันร่วมกันได้ Gherkin คือการกำหนดมาตรฐานรูปแบบการอธิบายนั้น โดย framework อย่าง Cucumber, Behave และ SpecFlow จะทำการ parse ไฟล์ Gherkin เพื่อรันการทดสอบ

นับตั้งแต่ทีมของผู้เขียนเริ่มเขียน acceptance test ด้วย Gherkin การสร้างฉันทามติในการประชุม review ระหว่าง QA กับนักพัฒนาว่า "หาก Scenario นี้ผ่านก็พร้อม release" ก็เร็วขึ้นอย่างเห็นได้ชัด

ข้อควรระวังในการนำไปใช้

Gherkin ไม่ใช่ยาวิเศษ หากออกแบบ granularity ของ step definition (โค้ด implementation ที่ทำงานอยู่เบื้องหลัง Given/When/Then) ผิดพลาด จะทำให้ step ที่คล้ายกันเพิ่มจำนวนมากขึ้นเรื่อยๆ และต้นทุนการบำรุงรักษาพุ่งสูงขึ้น นอกจากนี้ การเขียนการดำเนินการ UI ที่ละเอียดทีละขั้นตอนใน Gherkin มักทำให้เกิดความซ้ำซ้อน และในหลายกรณี การจำกัดการใช้งานเฉพาะการตรวจสอบ business rule แทนที่จะแปลง E2E test ทั้งหมดเป็น Gherkin จะให้ความคุ้มค่ากว่า

คำศัพท์ที่เกี่ยวข้อง

TDD

TDD (Test-Driven Development) คือวิธีการพัฒนาซอฟต์แวร์ที่เขียน Test ก่อนเขียนโค้ดจริง โดยวนซ้ำในวงจรสั้น ๆ ได้แก่ Test ล้มเหลว (RED) → การ Implement (GREEN) → การ Refactor (Refactor)

GraphRAG

สถาปัตยกรรม RAG รุ่นถัดไปที่ผสมผสาน Knowledge Graph และการค้นหาแบบ Vector เข้าด้วยกัน โดยใช้ประโยชน์จากความสัมพันธ์ระหว่าง Entity เพื่อเพิ่มความแม่นยำในการค้นหา