𝟯 สิ่งที่ไม่มีใครบอกคุณเกี่ยวกับ BDD

ชุดทดสอบ Cucumber ของคุณใช้เวลาในการรันถึง 40 นาที และคุณไม่สามารถอธิบายได้เลยว่า feature file แต่ละไฟล์ทดสอบอะไรบ้างโดยไม่ต้องไปไล่อ่านโค้ดหลายชั้น

หลายทีมนำ BDD มาใช้เพราะต้องการให้ผู้มีส่วนได้ส่วนเสียทางธุรกิจ (business stakeholders) สามารถอ่านผลการทดสอบได้ แต่แล้วคนเหล่านั้นก็เลิกอ่านไป สุดท้ายคุณจึงต้องเผชิญกับฝันร้ายในการบำรุงรักษา (maintenance nightmare)

นี่คือความจริง 3 ประการเกี่ยวกับ BDD

𝟭. Gherkin ไม่ใช่ภาษาโปรแกรมมิ่ง

เลิกเขียนสคริปต์ทดสอบในรูปแบบ Gherkin ที่ละเอียดเกินไป หาก scenario ของคุณต้องระบุทุกการคลิกและทุกช่องกรอกข้อมูล แสดงว่าคุณกำลังทำผิดวิธี

Gherkin ที่ไม่ดี:

  • Given ผู้ใช้กรอกอีเมล "test@example.com"
  • And ผู้ใช้กรอกรหัสผ่าน "Password123!"
  • And ผู้ใช้คลิก "Place Order"

Gherkin ที่ดี:

  • Given ผู้ใช้มีสินค้าที่พร้อมจะสั่งซื้อ
  • When ผู้ใช้ชำระเงินด้วยบัตรเครดิตที่ใช้งานได้
  • Then คำสั่งซื้อได้รับการยืนยัน

ส่วน "how" (ทำอย่างไร) ควรอยู่ใน step definitions ส่วน "what" (ทำอะไร) ควรอยู่ใน feature files จงเขียน feature files ให้เรียบง่าย เพื่อให้ Product Manager สามารถอ่านและเข้าใจได้ภายในไม่กี่วินาที

𝟮. Step definitions ไม่ใช่ dependency graph

อย่าทำให้ step definitions ไป import step definitions อื่นๆ เพราะจะทำให้เกิดความซับซ้อนที่พันกันยุ่งเหยิง หากขั้นตอนใดขั้นตอนหนึ่งล้มเหลว มันจะส่งผลเสียต่อสถานะ (state) ทั้งหมด

วิธีแก้ไขนั้นง่ายมาก:

  • แยก page objects ออกจาก step definitions
  • ใช้ shared domain layer
  • step definitions ควรเป็นเพียง thin wrappers ที่ทำหน้าที่เรียกใช้งาน domain objects

วิธีนี้จะทำให้ขั้นตอนของคุณเป็นแบบ stateless คุณจะสามารถเปลี่ยนโค้ดส่วนหนึ่งได้โดยไม่ทำให้ scenario อื่นๆ พังตามไปด้วย

𝟯. BDD คือโปรเจกต์ด้านการทำเอกสาร (documentation)

BDD คือเรื่องของการสื่อสาร ไม่ใช่แค่เรื่องของการทดสอบ การทดสอบเป็นเพียงผลพลอยได้เท่านั้น

หากคุณมุ่งเน้นแต่การเพิ่ม test coverage หรือความเร็วในการรันเท่านั้น คุณจะสูญเสียเป้าหมายหลักไป feature files ควรเป็นสิ่งแรกที่วิศวกรใหม่จะอ่านเพื่อทำความเข้าใจระบบของคุณ

หากคนคนหนึ่งไม่สามารถเข้าใจระบบของคุณได้จากการอ่าน feature files แสดงว่าชุดทดสอบ BDD ของคุณล้มเหลวแล้ว

สิ่งที่คุณควรทำในวันพรุ่งนี้:

  • เลือก feature file ที่แย่ที่สุดของคุณออกมา
  • เขียน scenario ใหม่ให้มีความยาวเพียง 3 ถึง 5 บรรทัด
  • ย้ายข้อมูลไปไว้ใน step definitions หรือ factories
  • เปลี่ยนจากการ import ระหว่าง step เป็นการใช้ domain objects แทน

คุณสามารถอธิบายระบบของคุณให้พนักงานใหม่ฟังโดยใช้เพียง feature files ภายในเวลา 5 นาทีได้หรือไม่? ถ้าไม่ได้ ก็เริ่มเขียนใหม่ได้เลย

3 สิ่งที่ไม่มีใครบอกคุณเกี่ยวกับ BDD ก่อนที่ Cucumber suite ของคุณจะกลายเป็นฝันร้ายในการบำรุงรักษา

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

นี่คือ 3 สิ่งที่คุณควรระวังก่อนที่มันจะสายเกินไป:

1. กับดักของ Gherkin: การเขียนแบบ Imperative แทนที่จะเป็น Declarative

ปัญหาที่พบบ่อยที่สุดคือการเขียน Gherkin ที่ลงรายละเอียดขั้นตอนทางเทคนิคมากเกินไป (Imperative) แทนที่จะเน้นไปที่พฤติกรรม (Declarative)

แบบที่ผิด (Imperative):

Given ฉันคลิกที่ปุ่ม "Login"
And ฉันพิมพ์ "user@example.com" ในช่องอีเมล
And ฉันพิมพ์ "password123" ในช่องรหัสผ่าน
And ฉันคลิกปุ่ม "Submit"
Then ฉันควรจะเห็นข้อความ "Welcome"

แบบที่ถูก (Declarative):

Given ฉันเข้าสู่ระบบด้วยบัญชีที่ถูกต้อง
Then ฉันควรจะเห็นหน้า Dashboard

ทำไมถึงเป็นปัญหา? เมื่อคุณเขียนแบบ Imperative ทุกครั้งที่ UI เปลี่ยน (เช่น เปลี่ยนชื่อปุ่ม หรือย้ายตำแหน่งช่องกรอกข้อมูล) คุณจะต้องตามไปแก้ไข Scenario และ Step Definitions จำนวนมหาศาล แต่ถ้าคุณเขียนแบบ Declarative คุณจะโฟกัสที่ "อะไร" (What) ไม่ใช่ "อย่างไร" (How) ซึ่งทำให้ Scenario ของคุณมีความทนทาน (Resilient) มากกว่า

2. การระเบิดของ Step Definition (Step Definition Explosion)

เมื่อทีมเริ่มเขียน Scenario มากขึ้นเรื่อยๆ โดยไม่มีการวางแผนที่ดี คุณจะเริ่มพบกับ Step Definitions ที่ซ้ำซ้อนหรือคล้ายกันมากจนแยกไม่ออก

คุณอาจจะมี:

  • Given ฉันล็อกอินเข้าสู่ระบบ
  • Given ฉันทำการเข้าสู่ระบบ
  • Given ฉันได้ทำการล็อกอินแล้ว

สิ่งนี้ทำให้เกิด "Maintenance Nightmare" เพราะเมื่อมีการเปลี่ยนแปลงตรรกะการล็อกอิน คุณต้องไล่แก้ Step Definitions หลายตัวที่ทำหน้าที่เหมือนกัน

วิธีแก้ไข:

  • ใช้ Parameterization ให้เป็นประโยชน์
  • สร้าง Library ของ Step Definitions ที่เป็นมาตรฐาน
  • ทำ Code Review สำหรับ Gherkin เหมือนที่คุณทำกับ Code ปกติ

3. ความรู้สึกปลอดภัยที่ผิดพลาด (The False Sense of Security)

หนึ่งในความเข้าใจผิดที่อันตรายที่สุดคือการคิดว่า "ถ้า BDD tests ผ่านหมด แปลว่าซอฟต์แวร์ไม่มีบั๊ก"

BDD ถูกออกแบบมาเพื่อทดสอบ พฤติกรรม (Behavior) และ ความต้องการทางธุรกิจ (Business Requirements) ไม่ใช่เพื่อทดสอบทุกซอกทุกมุมของโค้ด

หากคุณใช้ BDD เพื่อทดสอบ Logic เล็กๆ น้อยๆ ที่ควรจะเป็น Unit Test คุณกำลังทำสองอย่างที่ผิดพลาด:

  1. ทำให้ Cucumber suite รันช้าลงอย่างมหาศาล
  2. ทำให้การหาบั๊กในระดับ Logic ทำได้ยากขึ้นเพราะต้องรันผ่าน Layer ของ UI หรือ API เสมอ

กฎเหล็ก:

  • Unit Tests: ทดสอบ Logic, Edge cases, และอัลกอริทึม (เร็ว, ละเอียด)
  • BDD/Acceptance Tests: ทดสอบ User Flow และ Business Value (ช้ากว่า, เน้นภาพรวม)

บทสรุป

BDD เป็นเครื่องมือที่ทรงพลังหากใช้ให้ถูกวิธี อย่าปล่อยให้มันกลายเป็นภาระด้วยการเขียน Gherkin ที่ละเอียดเกินไป, การปล่อยให้ Step Definitions บวม, หรือการใช้มันแทนที่ Unit tests

จงจำไว้ว่า: เป้าหมายของ BDD คือการสื่อสาร ไม่ใช่แค่การทำ Automation

Source: https://dev.to/qawalah/3-things-nobody-tells-you-about-bdd-before-your-cucumber-suite-becomes-a-maintenance-nightmare-9c7

Optional learning community: https://t.me/GyaanSetuAi