BDD vs Gherkin

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

BDD ได้พัฒนามาจาก Test Driven Development (TDD) โดยมีแนวทางที่มุ่งเน้นไปที่ผู้ใช้มากขึ้น ช่วยให้การพัฒนาซอฟต์แวร์สอดคล้องกับความต้องการและคาดหวังของผู้ใช้

การเปลี่ยนแปลงจาก TDD มาสู่ BDD จะเน้นที่การทดสอบที่อิงพฤติกรรมของระบบจากมุมมองของผู้ใช้ แทนที่จะเป็นการทดสอบที่อิงจากโค้ด ซึ่งช่วยให้เข้าใจความต้องการของผู้ใช้ได้ลึกซึ้งขึ้น

BDD ใช้ภาษา Gherkin ในการเขียนข้อกำหนดในลักษณะที่เข้าใจได้ทั้งสำหรับทีมงานทางเทคนิคและไม่ทางเทคนิค ซึ่งช่วยเพิ่มการสื่อสารและลดความเข้าใจผิด

BDD ส่งเสริมการทำความเข้าใจร่วมกันเกี่ยวกับพฤติกรรมที่คาดหวังของซอฟต์แวร์ โดยให้ทุกฝ่ายที่เกี่ยวข้อง รวมทั้งผู้มีส่วนได้ส่วนเสียที่ไม่ใช่ทางเทคนิค เข้าใจเป้าหมายของโครงการอย่างชัดเจน ซึ่งช่วยหลีกเลี่ยงความไม่ตรงกันระหว่างความต้องการทางธุรกิจและสิ่งที่ทีมพัฒนา

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

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

BDD คืออะไร?

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

ข้อดีหลักสามประการของ BDD:

1. ความเข้าใจร่วมกัน: ทุกคนเข้าใจข้อกำหนดในแบบเดียวกัน
2. เอกสารที่มีชีวิต: ข้อกำหนดจะอัปเดตอยู่เสมอ
3. ข้อเสนอแนะเร็ว: ความเข้าใจผิดจะถูกค้นพบก่อนการพัฒนา

Three Amigos (สามเพื่อน)

ในวิธีการ BDD มีแนวปฏิบัติสำคัญคือเซสชัน "Three Amigos" (สามเพื่อน) ซึ่งบทบาทสำคัญสามบทบาทจะร่วมกันกำหนดข้อกำหนด:

1. ฝ่ายธุรกิจ/เจ้าของผลิตภัณฑ์: กำหนด "อะไร" และ "ทำไม"
2. นักพัฒนา: ประเมิน "อย่างไร" และระบุความซับซ้อนทางเทคนิค
3. ผู้ทดสอบ/QA: ระบุกรณีขอบ (Edge Cases) สถานการณ์เชิงลบ และเกณฑ์การยอมรับ

เซสชันเหล่านี้สร้างสถานการณ์ Gherkin ที่ทำหน้าที่เป็นเอกสารที่มีชีวิตของระบบ

Feature (คุณลักษณะ)

ทุกไฟล์ Gherkin เริ่มต้นด้วยคำสำคัญ Feature ที่อธิบายฟังก์ชันการทำงานระดับสูง:

Feature: การเข้าสู่ระบบของผู้ใช้ ในฐานะผู้ใช้ที่ลงทะเบียนแล้ว ฉันต้องการเข้าสู่ระบบแพลตฟอร์ม เพื่อเข้าถึงข้อมูลส่วนตัวของฉัน

Scenario (สถานการณ์)

Scenario แสดงถึงกรณีการใช้งานเฉพาะของคุณลักษณะ:

Scenario: เข้าสู่ระบบด้วยข้อมูลรับรองที่ถูกต้อง Given ผู้ใช้อยู่ที่หน้าเข้าสู่ระบบ When กรอกอีเมล "somchai@example.th" และรหัสผ่าน "Password123" And คลิกปุ่ม "เข้าสู่ระบบ" Then ถูกนำไปยังแดชบอร์ด And เห็นข้อความ "ยินดีต้อนรับ สมชาย"

Given-When-Then: หัวใจของ Gherkin

คำสำคัญสามคำหลักจัดโครงสร้างแต่ละสถานการณ์:

And และ But

สำหรับเพิ่มเงื่อนไขหลายรายการ:

Scenario: ลงทะเบียนด้วยข้อมูลไม่ครบ Given ผู้ใช้อยู่ที่หน้าลงทะเบียน And กรอกชื่อว่า "สมชาย" But ไม่ได้กรอกอีเมล When คลิกปุ่ม "ลงทะเบียน" Then เห็นข้อความผิดพลาด "กรุณากรอกอีเมล" And แบบฟอร์มไม่ถูกส่ง

Scenario Outline (โครงร่างสถานการณ์)

สำหรับทดสอบตรรกะเดียวกันด้วยข้อมูลที่แตกต่างกัน:

Scenario Outline: การตรวจสอบรหัสผ่าน Given ผู้ใช้อยู่ที่หน้าลงทะเบียน When กรอกรหัสผ่าน "<password>" Then ระบบแสดงข้อความ "<message>" Examples: | password | message | | abc | รหัสผ่านต้องมีอย่างน้อย 8 ตัวอักษร | | abcdefgh | รหัสผ่านต้องมีตัวเลข | | Abcdefg1 | รหัสผ่านถูกต้อง |

Background (พื้นหลัง)

Background กำหนดขั้นตอนร่วมสำหรับทุกสถานการณ์ใน Feature:

Feature: การจัดการตะกร้าสินค้า Background: Given ผู้ใช้เข้าสู่ระบบแล้ว And มีสินค้าอย่างน้อยหนึ่งรายการในแคตตาล็อก Scenario: เพิ่มสินค้าลงตะกร้า When เพิ่มสินค้า "Laptop Pro" ลงตะกร้า Then ตะกร้าแสดง 1 รายการ Scenario: ลบสินค้าออกจากตะกร้า Given ตะกร้ามีสินค้า "Laptop Pro" When ลบสินค้า "Laptop Pro" ออก Then ตะกร้าว่างเปล่า

Cucumber เป็นเฟรมเวิร์กที่แปลงข้อกำหนด Gherkin ให้เป็นการทดสอบที่ดำเนินการได้

กระบวนการทั้งหมด

1. เขียนข้อกำหนด ในไฟล์ .feature ด้วยไวยากรณ์ Gherkin
2. ใช้งาน Step Definitions: โค้ดที่เชื่อมแต่ละขั้นตอน Gherkin กับการดำเนินการอัตโนมัติ
3. รัน Cucumber: เฟรมเวิร์กอ่านไฟล์ .feature ค้นหา Step Definitions ที่ตรงกัน แล้วดำเนินการ
4. วิเคราะห์ผลลัพธ์: Cucumber สร้างรายงานของสถานการณ์ที่ผ่านและไม่ผ่าน

ตัวอย่าง Step Definition (Java)

@Given("ผู้ใช้อยู่ที่หน้าเข้าสู่ระบบ") public void userOnLoginPage() { driver.navigate().to("https://app.example.th/login"); } @When("กรอกอีเมล {string} และรหัสผ่าน {string}") public void enterCredentials(String email, String password) { driver.findElement(By.id("email")).sendKeys(email); driver.findElement(By.id("password")).sendKeys(password); } @Then("ถูกนำไปยังแดชบอร์ด") public void verifyRedirectToDashboard() { assertEquals("https://app.example.th/dashboard", driver.getCurrentUrl()); }

ตัวอย่าง Step Definition (JavaScript/TypeScript)

Given('ผู้ใช้อยู่ที่หน้าเข้าสู่ระบบ', async function() { await browser.url('/login'); }); When('กรอกอีเมล {string} และรหัสผ่าน {string}', async function(email, password) { await $('#email').setValue(email); await $('#password').setValue(password); }); Then('ถูกนำไปยังแดชบอร์ด', async function() { await expect(browser).toHaveUrl('/dashboard'); }); 

เขียนแบบ Declarative ไม่ใช่ Imperative

Imperative (ควรหลีกเลี่ยง):

When คลิกที่ช่อง "อีเมล" And พิมพ์ "somchai@example.th" And คลิกที่ช่อง "รหัสผ่าน" And พิมพ์ "Password123" And คลิกปุ่ม "เข้าสู่ระบบ"

Declarative (แนะนำ):

When เข้าสู่ระบบด้วยอีเมล "somchai@example.th" และรหัสผ่าน "Password123"

หนึ่งสถานการณ์ หนึ่งพฤติกรรม

แต่ละสถานการณ์ควรทดสอบพฤติกรรมเดียว สถานการณ์ที่ยาวเกินไปหรือตรวจสอบหลายพฤติกรรมจะยากต่อการบำรุงรักษาและแก้จุดบกพร่อง

ใช้ภาษาของโดเมน

เขียนสถานการณ์โดยใช้ศัพท์ทางธุรกิจ ไม่ใช่ภาษาของโค้ด ถ้าธุรกิจพูดถึง "คำสั่งซื้อ" อย่าใช้ "เร็คคอร์ดในฐานข้อมูล"

สถานการณ์ที่เป็นอิสระ

แต่ละสถานการณ์ต้องสามารถดำเนินการได้แบบแยกส่วน โดยไม่ต้องพึ่งพาการดำเนินการของสถานการณ์อื่นก่อนหน้า

คุณลักษณะที่น่าสนใจของ Gherkin คือรองรับกว่า 70 ภาษา รวมถึงภาษาไทย:

# language: th โครงหลัก: การจัดการคำสั่งซื้อ ในฐานะผู้ดูแลร้านค้า ฉันต้องการจัดการคำสั่งซื้อ เพื่อให้บริการได้อย่างมีประสิทธิภาพ เหตุการณ์: สร้างคำสั่งซื้อใหม่ กำหนดให้ ลูกค้า "สมชาย" ลงทะเบียนแล้ว เมื่อ สร้างคำสั่งซื้อสินค้า "เครื่องชงกาแฟ" ดังนั้น คำสั่งซื้อถูกสร้างด้วยสถานะ "รอดำเนินการ" และ อีเมลยืนยันถูกส่งไป

ข้อดีที่สำคัญที่สุดของ Gherkin คือไฟล์ .feature ทำหน้าที่เป็นเอกสารที่อัปเดตอยู่เสมอของระบบ:

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

Gherkin เป็นภาษาโปรแกรมมิ่งหรือไม่?

ไม่ Gherkin เป็นภาษาข้อกำหนด (DSL - Domain Specific Language) ที่ออกแบบมาเพื่ออธิบายพฤติกรรมของซอฟต์แวร์ในรูปแบบที่อ่านได้ ไม่มีตรรกะการเขียนโปรแกรม ซึ่งจะถูกนำไปใช้งานใน Step Definitions ด้วยภาษาโปรแกรมมิ่งจริง

ใครควรเขียนสถานการณ์ Gherkin?

ในอุดมคติ สถานการณ์ Gherkin ควรเขียนร่วมกันในเซสชัน Three Amigos เจ้าของผลิตภัณฑ์กำหนดพฤติกรรมที่คาดหวัง ผู้ทดสอบระบุกรณีขอบ และนักพัฒนาตรวจสอบความเป็นไปได้ทางเทคนิค

Gherkin ใช้ได้กับ Cucumber เท่านั้นหรือ?

ไม่ Gherkin เป็นรูปแบบมาตรฐานที่รองรับโดยเฟรมเวิร์กทดสอบหลายตัว ได้แก่ SpecFlow (.NET), Behave (Python), Behat (PHP), Karate (ทดสอบ API) และอื่นๆ อีกมากมาย

ควรมีกี่สถานการณ์ใน Feature หนึ่ง?

ไม่มีจำนวนตายตัว แต่โดยทั่วไป Feature หนึ่งควรมีระหว่าง 3 ถึง 10 สถานการณ์ หากมีมากเกินไป Feature อาจกว้างเกินไปและควรแบ่งออก

Gherkin เหมาะกับ Unit Test หรือไม่?

โดยทั่วไปไม่ Gherkin ถูกออกแบบสำหรับการทดสอบยอมรับ (Acceptance Test) และการทดสอบบูรณาการ (Integration Test) ระดับสูง สำหรับ Unit Test เฟรมเวิร์กแบบดั้งเดิม (JUnit, pytest, Jest) มีประสิทธิภาพและเหมาะสมกว่า