BDD: คืออะไร สถานการณ์พฤติกรรมและเฟรมเวิร์ก

BDD คืออะไร?

Behavior-Driven Development เป็นวิวัฒนาการของ TDD ที่เสนอโดย Dan North ในปี 2006 เพื่อตอบปัญหาการกำหนดทดสอบ ใน TDD นักพัฒนาเขียนทดสอบหนึ่ง แต่คำถาม “จะทดสอบอะไรแน่?” ยังคงเปิดอยู่ BDD แก้ปัญหานี้โดยเปลี่ยนโฟกัสจากการทดสอบโค้ดไปที่ การอธิบายพฤติกรรมของระบบ จากมุมมองของผู้ใช้

นวัตกรรมสำคัญของ BDD คือ ภาษากลาง สำหรับผู้มีส่วนร่วมในโครงการทั้งหมด นักพัฒนา ผู้ทดสอบ นักวิเคราะห์ และลูกค้าหารือเกี่ยวกับสถานการณ์ด้วยภาษาที่เป็นหนึ่งเดียวซึ่งทำหน้าที่เป็นทดสอบที่ดำเนินการได้ในเวลาเดียวกัน สิ่งนี้กำจัดปัญหา “โทรศัพท์เสีย” แบบคลาสสิกที่ความต้องการสูญเสียความหมายเมื่อส่งผ่านจากนักวิเคราะห์ถึงนักพัฒนา

ประวัติของการเกิด BDD

Dan North กำหนด BDD ในปี 2006 ในบทความ “Introducing BDD” บนบล็อก ThinkCode เขาสังเกตว่าชื่อทดสอบใน TDD มักถูกกำหนดในศัพท์การนำไปใช้งาน (“testAddUser”) มากกว่าศัพท์พฤติกรรม (“ผู้ใช้ควรสามารถลงทะเบียนด้วยอีเมล”) BDD แทนที่คำว่า “test” ด้วย “should” และ “assert” ด้วย “expect” โดยเปลี่ยนโฟกัสไปที่คุณค่าสำหรับผู้ใช้

BDD เป็นการปฏิบัติการสื่อสาร

ตามการศึกษาของ มหาวิทยาลัยเคมบริดจ์ (2021) โครงการที่ใช้สถานการณ์ BDD ในการสื่อสารกับลูกค้าลดข้อผิดพลาดความต้องการลง 35% เมื่อเทียบกับข้อกำหนดแบบดั้งเดิมในเอกสารข้อความ สถานการณ์ที่ดำเนินการได้ไม่อนุญาตให้มีถ้อยคำที่คลุมเครือ — แต่ละ Given-When-Then ผ่านหรือไม่ผ่าน

ภาษา Gherkin และไวยากรณ์

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

Feature: Login
  Scenario: Successful login with valid credentials
    Given the user is on the login screen
    When they enter valid username and password
    Then they should see the home screen

คำหลักของ Gherkin

Gherkin กำหนด คำหลัก พื้นฐานหลายคำ Feature อธิบายฟังก์ชันการทำงาน Scenario อธิบายสถานการณ์เฉพาะ Given อธิบายเงื่อนไขเบื้องต้น When อธิบายการกระทำ Then อธิบายผลลัพธ์ที่คาดหวัง นอกจากนี้ And และ But ใช้เพื่อรวมหลายเงื่อนไข

โครงสร้างไฟล์ .feature

ไฟล์ Gherkin มีนามสกุล .feature และถูกเก็บในไดเรกทอรี src/test/resources/features/ ในโครงการ Android แต่ละไฟล์เริ่มต้นด้วยคำอธิบาย Feature ตามด้วย Scenario หนึ่งหรือหลายรายการ สำหรับการกำหนดพารามิเตอร์ ใช้ Scenario Outline กับตาราง Examples — สิ่งนี้อนุญาตให้รันสถานการณ์เดียวกันกับข้อมูลที่แตกต่างกัน

Feature: Calculator
  Scenario Outline: Addition of two numbers
    Given the calculator is running
    When I add <a> and <b>
    Then the result should be <result>

    Examples:
      | a | b | result |
      | 2 | 3 | 5     |
      | 0 | 0 | 0     |
      | -1| 1 | 0     |

รูปแบบ Given-When-Then

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

Given: บริบท

บล็อก Given อธิบายสถานะของระบบก่อนเริ่มสถานการณ์: ข้อมูลใดที่มีอยู่ ส่วนประกอบใดทำงานอยู่ แอปพลิเคชันอยู่ในโหมดใด ในบริบทมือถือ สิ่งนี้อาจเป็น “ผู้ใช้เข้าสู่ระบบแล้ว”, “ตะกร้าไม่ว่าง” หรือ “อุปกรณ์อยู่ในโหมดออฟไลน์”

When: การกระทำ

บล็อก When อธิบายเหตุการณ์ที่ถูกกระตุ้นโดยผู้ใช้หรือระบบ: กดปุ่ม รับการแจ้งเตือน push การตอบสนองของเซิร์ฟเวอร์ ในแอปพลิเคชันมือถือ สิ่งนี้มักสอดคล้องกับการเรียกเมธอด ViewModel หรือการคลิกองค์ประกอบ UI

Then: ผลลัพธ์

บล็อก Then อธิบายการเปลี่ยนแปลงสถานะที่คาดหวัง: การเปลี่ยนหน้าจอ การเรียก API การอัปเดตฐานข้อมูล การตรวจสอบใน Then ต้องวัดได้และไม่คลุมเครือ — สิ่งเหล่านี้กลายเป็น assertions ในโค้ดที่ดำเนินการได้

BDD และ TDD: การเปรียบเทียบแนวทาง

BDD และ TDD มักสับสน แม้ว่าจะเป็นระดับวินัยที่แตกต่างกัน TDD เป็นเทคนิคการออกแบบในระดับโค้ด: “วิธีเขียนการนำไปใช้งาน” BDD เป็นเทคนิคการกำหนดในระดับความต้องการ: “สิ่งที่ระบบควรทำ”

การเสริมกันในโครงการ

โครงการมือถือที่ดีที่สุดใช้ TDD ในระดับคลาสเดี่ยว (เลเยอร์โดเมน) และ BDD ในระดับสถานการณ์ (เลเยอร์ฟีเจอร์) สิ่งนี้ให้ ความครอบคลุมสองเท่า: TDD รับประกันความถูกต้องของการนำไปใช้งาน BDD รับประกันความถูกต้องของความเข้าใจความต้องการ Google ในการปฏิบัติภายในใช้การผสมผสานของ TDD และ BDD สำหรับแอปพลิเคชัน Android ตามที่ระบุในเอกสาร Android Testing (2024)

เครื่องมือ BDD สำหรับการพัฒนามือถือ

ระบบนิเวศ BDD รวมถึงเฟรมเวิร์กสำหรับแพลตฟอร์มและภาษาการพัฒนามือถือยอดนิยมทั้งหมด การเลือกเครื่องมือขึ้นอยู่กับสแต็กเทคโนโลยีและระดับอัตโนมัติ

Cucumber สำหรับ Android

Cucumber เป็นเฟรมเวิร์ก BDD ที่ได้รับความนิยมมากที่สุด ทำงานกับสถานการณ์ Gherkin สำหรับโครงการ Android ใช้ไลบรารี io.cucumber:cucumber-android ซึ่งรวมเข้ากับเครื่องมือทดสอบ UI Espresso และ Compose Test Cucumber รองรับ Kotlin และ Java ทำให้เป็นตัวเลือกสากลสำหรับสตูดิโอที่ใช้ทั้งสองภาษา

SpecFlow สำหรับ Xamarin

SpecFlow เป็นเฟรมเวิร์ก BDD สำหรับระบบนิเวศ .NET ใช้ในโครงการ Xamarin.Forms และ .NET MAUI SpecFlow รวมเข้ากับ NUnit และ xUnit และ step definitions ของมันเขียนด้วย C# สำหรับโครงการมือถือ SpecFlow อนุญาตให้ใช้สถานการณ์ซ้ำระหว่างเวอร์ชัน Android และ iOS ของแอปพลิเคชันบนฐานโค้ดที่ใช้ร่วมกัน

Quick/Nimble สำหรับ iOS

สำหรับการพัฒนา iOS ด้วย Swift มีเฟรมเวิร์ก BDD Quick และ Nimble Quick ให้ DSL สำหรับอธิบายสถานการณ์ในสไตล์ describe/it และ Nimble ให้ matchers ที่มีไวยากรณ์อ่านง่าย แม้ว่าเฟรมเวิร์กเหล่านี้จะไม่ได้ใช้ Gherkin โดยตรง แต่พวกเขานำหลักการ BDD ไปใช้: อธิบายพฤติกรรมในภาษาที่ทั้งทีมเข้าใจ

ตัวอย่างสถานการณ์ BDD และโค้ด

มาดูตัวอย่าง BDD ที่สมบูรณ์ในโครงการ Android: สถานการณ์ชำระเงินคำสั่งซื้อ ก่อนอื่นเราเขียนสถานการณ์ Gherkin จากนั้น step definitions ใน Kotlin

หลักการทำงานของ BDD: three amigos

วิธีการ BDD ขึ้นอยู่กับการประชุม three amigos — สามบทบาท: นักพัฒนา ผู้ทดสอบ และนักวิเคราะห์ พวกเขาเขียนสถานการณ์ร่วมกันก่อนเริ่มพัฒนา กำหนดความเข้าใจร่วมกันของความต้องการ หากหนึ่งในสามผู้เข้าร่วมไม่เข้าใจสถานการณ์ หมายความว่าความต้องการถูกกำหนดอย่างคลุมเครือ แนวปฏิบัตินี้ถูกอธิบายในหนังสือ “Discovery: Explore Behaviour Using Examples” (Gáspár & North, 2021) และเป็นส่วนบังคับของกระบวนการ BDD ในทีมที่เติบโตเต็มที่

สถานการณ์ Gherkin การชำระเงินคำสั่งซื้อ

Feature: Order Checkout
  Scenario: Apply promo code to cart
    Given the user has items in the cart
    And the total amount is $100
    When they apply promo code "WELCOME10"
    Then the discount should be $10
    And the final total should be $90

Step Definitions ใน Kotlin

Step definitions คือโค้ดที่เชื่อมต่อสถานการณ์ Gherkin กับการนำไปใช้งานทดสอบ แต่ละขั้นตอนเป็นเมธอดที่มีคำอธิบายประกอบที่สอดคล้องกับคำหลัก Gherkin

class CheckoutSteps {
    private val cart = Cart()
    private val checkout = CheckoutUseCase()

    fun `user has items in the cart`() {
        cart.addItem(Item("Phone", 100.0))
    }

    fun `apply promo code`(code: String) {
        checkout.applyPromo(cart, code)
    }

    fun `discount should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getDiscount())
    }

    fun `final total should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getTotal())
    }
}

การบูรณาการกับ Cucumber Android

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

// build.gradle.kts
dependencies {
    androidTestImplementation("io.cucumber:cucumber-android:7.18.0")
    androidTestImplementation("io.cucumber:cucumber-junit:7.18.0")
}

// CucumberOptions annotation
@RunWith(Cucumber::class)
@CucumberOptions(features = "features", glue = ["com.app.steps"])
class CucumberTestRunner

ความท้าทายของการนำ BDD ไปใช้ในโครงการมือถือ

การนำ BDD ไปใช้ในการพัฒนามือถือมาพร้อมกับความยากลำบากในทางปฏิบัติหลายประการ การเข้าใจปัญหาเหล่านี้ช่วยให้ทีมหลีกเลี่ยงความผิดหวังและสร้างกระบวนการ BDD ที่ยั่งยืน

การบำรุงรักษาไฟล์ .feature

ปัญหาหลักคือ การสูญเสียการซิงค์ ระหว่างสถานการณ์ Gherkin และโค้ดการผลิต หากนักพัฒนาเปลี่ยน APIs โดยไม่อัปเดต step definitions ไฟล์ .feature จะไม่ตรงกับการนำไปใช้งาน วิธีแก้คือรันทดสอบ BDD ในไปป์ไลน์ CI/CD และต้องการสถานะสีเขียวสำหรับคำขอรวม แนวปฏิบัติ “BDD as a gating mechanism” ถูกอธิบายในเอกสาร Cucumber (2024) และเป็นมาตรฐานในอุตสาหกรรม

ประสิทธิภาพทดสอบ BDD

สถานการณ์ BDD ใน Cucumber รันเป็นทดสอบที่ถูกตรวจจับบนอุปกรณ์ Android หรืออีมูเลเตอร์ สิ่งนี้ช้ากว่าทดสอบหน่วยปกติบน JVM 10–50 เท่า การทดสอบการยอมรับครั้งเดียวอาจใช้เวลา 20–30 นาทีสำหรับแอปพลิเคชัน Android ขนาดใหญ่ แนะนำให้รันทดสอบ BDD ในงาน CI แยกต่างหากในเวลากลางคืน ในขณะที่ทดสอบหน่วยรันทุก push กลยุทธ์นี้สร้างสมดุลระหว่างความเร็วของคำติชมและความครอบคลุมของสถานการณ์

การฝึกอบรมทีมใน Gherkin

การเปลี่ยนไปใช้ BDD ต้องการการฝึกอบรมไม่เพียงนักพัฒนา แต่ยังรวมถึง นักวิเคราะห์และผู้ทดสอบ Gherkin เป็นภาษาง่าย แต่การเขียนสถานการณ์ที่ดีต้องการการฝึกฝน ข้อผิดพลาดทั่วไปของผู้เริ่มต้น: สถานการณ์ยาวเกินไป (มากกว่า 10 ขั้นตอน) ผสม Given-When-Then ใช้ศัพท์เทคนิคในสถานการณ์ธุรกิจ ตาม BDD Academy (2024) ทีมต้องการเฉลี่ย 4–6 สปรินต์เพื่อบรรลุความเชี่ยวชาญในการเขียนสถานการณ์ BDD