ทีมบอกให้ทำ BDD เราก็ทำ เขียน Given-When-Then มาเป็นปี
แต่ก็ตอบไม่ได้ว่าสิ่งที่ทำอยู่เนี่ย มันดีจริง หรือแค่เขียนตาม syntax ไปวันๆ
.
Scenario ก็ออกมาครบ รันผ่านหมด
เขียวทั้งกระดาน
ปิด ticket สบายใจ
จนมีคนมาดู feature file แล้วกุมหัวนั่นแหละ
“อันนี้มันเทสอะไรนะ”
“อธิบายได้มั้ย อ่านแล้วไม่เข้าใจเลย”
.
Test ที่แค่ “รันผ่าน” กับ Test ที่เอาไปใช้ “สื่อสารได้จริง” มันคนละเรื่องกันเลยนะคะ
เขียวหมด แปลว่าไม่พัง แต่ไม่ได้แปลว่าคนอื่นอ่านแล้วเข้าใจว่าเรากำลังเทสอะไรอยู่
วันนี้พี่กิ่งเลยลองรวบรวม 5 สัญญาณเตือน จากสิ่งที่เจอมาบ่อยๆ
ที่บอกว่า Given-When-Then ของเราอาจจะทำให้คนอื่นกุมหัวได้
ลองเอาไปเช็คกับสิ่งที่เรากำลังเขียนอยู่ได้เลยค่ะ
.
1️⃣ And… And… And… And… And…
❌ เมื่อไหร่ที่เจอ And ติดกันยาวๆ เยอะๆ เนี่ย หยุดเลยค่ะ
มันแปลว่าเรากำลังยัดหลายเรื่องเอาไว้ใน scenario เดียว
ลองถอยออกมาดูก่อนว่า เป้าหมายของเราคืออะไร แล้วเราจะแยกออกมาเป็นหลาย scenario ได้ยังไงบ้าง
.
2️⃣ Actor ไม่ชัด
❌ เรามักจะเผลอเขียน Actor ไปกว้างๆ เพราะคิดว่าคนอื่นจะเข้าใจอยู่แล้ว แต่บางทีคนที่ไม่ได้มี context เดียวกันกับเรา อาจจะงงได้ค่ะ
อย่างเช่น Given a user is logged in มันคือ user แบบไหน เป็นลูกค้า เป็น admin ถ้าไม่ได้บอกไว้ คนอื่นก็ต้องเดาเอาว่ากำลังเทสพฤติกรรมของใครอยู่
.
3️⃣ บอก “ขั้นตอน” แทนที่จะบอก “พฤติกรรม”
❌ Given user clicks login, then enters email, then clicks submit
มันเป็นการเล่า step ขั้นตอนว่าต้องทำอะไร กดอะไร คนจะเห็นแค่ว่าเรา “ทำอะไรบ้าง” แต่อ่านไม่เข้าใจเลยว่าต้องการอะไร กำลังเช็คพฤติกรรมอะไรอยู่ ลองคิดให้ดีว่าพฤติกรรมจริงๆ ที่บรรทัดนี้ต้องการคืออะไร แล้วเขียนแค่นั้นพอ
.
4️⃣ Then เช็คหลายจุดใน scenario เดียว
❌ Then user sees success message and order is created and email is sent
เรากำลังเช็ค 3 behaviors ในประโยคเดียวเลยค่ะ เช็ค UI ว่า success message ขึ้นถูก เช็คว่าสร้างออเดอร์ถูก และเช็คว่าส่งอีเมลถูก
1 scenario ควรจะแยกให้ชัดว่าจะเทสเรื่องไหนกันแน่ ถ้ามันพัง ก็จะได้รู้ว่าอะไรพัง
.
5️⃣ เผลอใส่ภาษา technical เข้ามา
❌ When user clicks #submit-btn
Then API return 200
ถ้าเป็นการเทส feature ต้องระวังเลยค่ะ เพราะคนอ่านที่ไม่ได้ทำงาน technical อาจจะงงไปเลยว่าเรากำลังหมายถึงอะไร
.
💬 พี่กิ่งว่าเรื่องนี้เป็นเรื่องที่สำคัญกว่าที่หลายคนคิดค่ะ
BDD ที่ดี มันไม่ได้มีไว้แค่ให้เรารันเทสได้ หรือเขียน automate ได้
แต่มันจะกลายเป็น living documentation คือ เอกสารที่มีชีวิต ที่จะคอยอัปเดตตามสิ่งที่ระบบเป็นจริงๆ เพราะเรารู้อยู่แล้วว่า ถ้าไม่ได้เป็นตามนั้นแปลว่าเทสจะรันไม่ผ่าน
ถ้าทำได้ดี มันจะกลายเป็นเอกสารตรงกลางที่ทีมสามารถมาใช้ร่วมกันได้
เพื่อให้ทุกคนเห็นภาพตรงกันว่า behavior ของระบบมันเป็นยังไง
แต่ถ้า scenario ของเรามีแต่ And ยาวๆ ติดกันเป็นพรืด
Actor ไม่ชัด ไม่รู้ว่าใครทำอะไร
มีภาษา coding ภาษา technical ปนมาด้วย
มันก็จะเป็นแค่ test script ที่เขียนด้วย Gherkin format เท่านั้นเอง ไม่ใช่ BDD จริงๆ
.
📌 เริ่มเลยวันนี้
ลองหยิบ scenario ที่กำลังเขียนอยู่ตอนนี้ มาเช็คเร็วๆ ดูนะคะว่าตรงกับข้อไหนบ้าง
ยังไม่ต้องแก้ทั้งหมดก็ได้ แค่ลองเริ่มเช็คก็ถือว่าได้ก้าวไปข้างหน้าแล้วค่ะ