BDD - TDD ในรูปแบบ BDD

ใน TDD คำว่า“ การทดสอบการยอมรับ” ทำให้เข้าใจผิด การทดสอบการยอมรับเป็นตัวแทนของพฤติกรรมที่คาดหวังของระบบ ในการปฏิบัติแบบ Agile จะเน้นการทำงานร่วมกันของทั้งทีมและการมีปฏิสัมพันธ์กับลูกค้าและผู้มีส่วนได้ส่วนเสียอื่น ๆ สิ่งนี้ทำให้เกิดความจำเป็นในการใช้คำศัพท์ที่ทุกคนที่เกี่ยวข้องในโครงการเข้าใจได้ง่าย

TDD ทำให้คุณคิดถึงสิ่งที่จำเป็น Behavior และด้วยเหตุนี้คำว่า 'พฤติกรรม' จึงมีประโยชน์มากกว่าคำนี้ ‘Test’. BDD คือ Test Driven Development พร้อมคำศัพท์ที่เน้นพฤติกรรมไม่ใช่การทดสอบ

ในคำพูดของ Dan North“ ฉันพบว่าการเปลี่ยนจากการคิดในการทดสอบไปสู่การคิดในพฤติกรรมนั้นลึกซึ้งมากจนฉันเริ่มอ้างถึง TDD ว่า BDD หรือ Behavior Driven Development” TDD มุ่งเน้นไปที่การทำงานของบางสิ่ง BDD มุ่งเน้นไปที่สาเหตุที่เราสร้างมันขึ้นมา

BDD ตอบคำถามต่อไปนี้ที่นักพัฒนามักจะเผชิญ -

คำถาม	ตอบ
จะเริ่มต้นที่ไหน?	นอก - ใน
จะทดสอบอะไร	เรื่องราวของผู้ใช้
สิ่งที่ไม่ต้องทดสอบ?	อย่างอื่น

คำตอบเหล่านี้ทำให้เกิดกรอบเรื่องราวดังนี้ -

Story Framework

ในฐานะที่เป็น [Role]

ฉันต้องการ [Feature]

ดังนั้น [Benefit]

ซึ่งหมายความว่า 'เมื่อก Feature ถูกดำเนินการผลลัพธ์ที่ได้ Benefit เป็นของบุคคลที่เล่นไฟล์ Role.'

BDD ตอบคำถามต่อไปนี้เพิ่มเติม -

คำถาม	ตอบ
ต้องทดสอบเท่าไหร่ในครั้งเดียว?	เน้นน้อยมาก
สิ่งที่เรียกว่าการทดสอบของพวกเขา?	เทมเพลตประโยค
จะเข้าใจได้อย่างไรว่าทำไมการทดสอบจึงล้มเหลว	เอกสารประกอบ

คำตอบเหล่านี้ทำให้เกิดกรอบตัวอย่างดังนี้ -

Example Framework

Given บริบทเริ่มต้นบางส่วน

When เหตุการณ์เกิดขึ้น

Then ตรวจสอบผลลัพธ์บางอย่าง

ซึ่งหมายความว่า 'เริ่มจากบริบทเริ่มต้นเมื่อมีเหตุการณ์ใดเหตุการณ์หนึ่งเกิดขึ้นเรารู้ว่าผลลัพธ์เป็นอย่างไร should be. '

ดังนั้นตัวอย่างแสดงพฤติกรรมที่คาดหวังของระบบ ตัวอย่างนี้ใช้เพื่อแสดงสถานการณ์ต่างๆของระบบ

เรื่องราวและสถานการณ์

ขอให้เราพิจารณาภาพประกอบต่อไปนี้โดย Dan North เกี่ยวกับระบบ ATM

เรื่องราว

As a ลูกค้า,

I want ถอนเงินสดจากตู้เอทีเอ็ม

so that ฉันไม่ต้องรอเข้าแถวที่ธนาคาร

สถานการณ์

มีสองสถานการณ์ที่เป็นไปได้สำหรับเรื่องราวนี้

Scenario 1 - บัญชีเป็นเครดิต

Given บัญชีเป็นเครดิต

And บัตรถูกต้อง

And ตู้มีเงินสด

When ลูกค้าขอเงินสด

Then ตรวจสอบให้แน่ใจว่าบัญชีถูกหัก

And ตรวจสอบให้แน่ใจว่ามีการจ่ายเงินสด

And ตรวจสอบให้แน่ใจว่าบัตรถูกส่งคืน

Scenario 2 - บัญชีถูกถอนเกินขีด จำกัด เงินเบิกเกินบัญชี

Given บัญชีถูกถอนออกไป

And บัตรถูกต้อง

When ลูกค้าขอเงินสด

Then ตรวจสอบว่าข้อความปฏิเสธปรากฏขึ้น

And ตรวจสอบให้แน่ใจว่าไม่มีการจ่ายเงินสด

And ตรวจสอบให้แน่ใจว่าบัตรถูกส่งคืน

เหตุการณ์เหมือนกันในทั้งสองสถานการณ์ แต่บริบทแตกต่างกัน ดังนั้นผลลัพธ์จึงแตกต่างกัน

วงจรการพัฒนา

วัฏจักรการพัฒนาสำหรับ BDD คือไฟล์ outside-in แนวทาง

Step 1- เขียนตัวอย่างมูลค่าทางธุรกิจระดับสูง (ภายนอก) (โดยใช้ Cucumber หรือ RSpec / Capybara) ที่เป็นสีแดง (RSpec สร้างเฟรมเวิร์ก BDD ในภาษา Ruby)

Step 2 - เขียนตัวอย่าง RSpec ระดับล่าง (ด้านใน) สำหรับขั้นตอนแรกของการใช้งานที่เป็นสีแดง

Step 3 - ใช้รหัสขั้นต่ำเพื่อส่งผ่านตัวอย่างระดับล่างนั้นดูเป็นสีเขียว

Step 4 - เขียนตัวอย่าง RSpec ระดับล่างถัดไปที่ผลักไปสู่ขั้นตอนที่ 1 ซึ่งจะเป็นสีแดง

Step 5 - ทำซ้ำขั้นตอนที่ 3 และขั้นตอนที่ 4 จนกระทั่งตัวอย่างระดับสูงในขั้นตอนที่ 1 เป็นสีเขียว

Note - ควรคำนึงถึงประเด็นต่อไปนี้ -

• Red/green state คือสถานะการอนุญาต

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

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