รูปแบบ Gherkin
Gherkin記法 (สัญกรณ์ Gherkin) คือรูปแบบโครงสร้างที่ใช้อธิบายพฤติกรรมของซอฟต์แวร์ในลักษณะภาษาธรรมชาติ โดยแบ่งออกเป็น 3 ขั้นตอน ได้แก่ Given (เงื่อนไขเริ่มต้น), When (การกระทำ) และ Then (ผลลัพธ์) สัญกรณ์นี้ถูกใช้อย่างแพร่หลายในฐานะรูปแบบมาตรฐานของไฟล์ .feature ที่เครื่องมือทดสอบอัตโนมัติ Cucumber ใช้อ่านข้อมูล
ทำไมต้องใช้ Gherkin
ในหลายทีมพัฒนา นักพัฒนาจัดการเอกสารข้อกำหนดการทดสอบด้วยโค้ด ในขณะที่ฝ่ายธุรกิจจัดการด้วยเอกสารภาษาญี่ปุ่นหรือภาษาอังกฤษแยกจากกัน ทุกครั้งที่มีการเปลี่ยนแปลงข้อกำหนด จำเป็นต้องอัปเดตทั้งสองส่วน ทำให้เกิดความคลาดเคลื่อนสะสมขึ้นเรื่อยๆ
Gherkin notation แก้ปัญหานี้ด้วยแนวทางที่เรียกว่า "เอกสารข้อกำหนดที่สามารถรันได้" ไวยากรณ์ของมันใกล้เคียงกับภาษาธรรมชาติที่ผู้รับผิดชอบด้านธุรกิจสามารถอ่านได้ ในขณะเดียวกันก็สามารถรันเป็นการทดสอบอัตโนมัติได้โดยตรง เนื่องจากเอกสารข้อกำหนดและโค้ดทดสอบอยู่ในไฟล์เดียวกัน จึงยากที่จะเกิดความแตกต่างกันในเชิงโครงสร้าง
ไวยากรณ์พื้นฐาน
โครงสร้างทั่วไปของไฟล์ .feature มีดังนี้
1Feature: ユーザーログイン
2
3 Scenario: 正しい認証情報でログインできる
4 Given ログインページを表示している
5 When メールアドレス "user@example.com" を入力する
6 And パスワード "correct-password" を入力する
7 And ログインボタンをクリックする
8 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 จะให้ความคุ้มค่ากว่า
บทความที่กล่าวถึงคำศัพท์นี้
- Eval-Driven Development (EDD) คืออะไร? กระบวนการพัฒนา AI ที่เน้นการประเมินผลเป็นหลักเรียนรู้วิธีใช้ EDD เพื่อนำตัวชี้วัดมาปรับใช้ตลอดวงจรการทำงานแทนการใช้สัญชาตญาณ พร้อมขั้นตอนการปรับแต่ง Prompt และ Parameter แบบอัตโนมัติ
- การพัฒนาจะเปลี่ยนไปอย่างไรด้วย Claude Mythos และ Fable: จากการตรวจสอบ "การเขียนโค้ดที่ถูกต้อง" สู่ "การทำงานที่ถูกต้อง"Claude Mythos และ Fable 5 จาก Anthropic โดดเด่นด้านงานเอเจนต์ระยะยาว เปลี่ยนการพัฒนาจากการเน้น "โค้ดที่ถูกต้อง" สู่ "ผลลัพธ์ที่ถูกต้อง" พร้อมเจาะลึกการใช้งานร่วมกับ /goal และ Dynamic workflows เพื่อการมอบหมายงานอย่างมีประสิทธิภาพตามข้อมูลทางการ
- วิธีเลือกใช้ Fine-tuning และ RAG: คู่มือเปรียบเทียบตามต้นทุน ความแม่นยำ และการใช้งานจริงเลือกใช้ Fine-tuning หรือ RAG ดี? เปรียบเทียบ 4 ปัจจัยหลัก (ต้นทุน, ความแม่นยำ, การอัปเดต, ความปลอดภัย) พร้อมเกณฑ์การเลือกที่เหมาะสมกับธุรกิจคุณ
คำศัพท์ที่เกี่ยวข้อง
การทดสอบ E2E
การทดสอบ E2E (End-to-End Testing) คือวิธีการทดสอบที่จำลองการกระทำของผู้ใช้เป็นจุดเริ่มต้น แล้วส่งผ่า
การทดสอบการยอมรับ
การทดสอบการยอมรับ (Acceptance Test) คือวิธีการทดสอบที่ใช้ตรวจสอบว่าฟีเจอร์ที่พัฒนาขึ้นนั้นตรงตามความ
SSM (AWS Systems Manager)
AWS Systems Manager (SSM) คือ AWS Managed Service ที่ใช้สำหรับบริหารจัดการและดำเนินการ EC2 Instance
ATDD
ATDD (Acceptance Test-Driven Development) คือวิธีการพัฒนาซอฟต์แวร์ที่ทีมงานทั้งหมดร่วมกันกำหนดเกณฑ์ก