รูปแบบ Gherkin

## ทำไมต้องใช้ 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 จะให้ความคุ้มค่ากว่า