ความสัมพันธ์ระหว่าง BDD และ TDD

ความสัมพันธ์ของ BDD และ TDD คืออะไร?

จากสิ่งที่ฉันเข้าใจ BDD เพิ่มสองสิ่งสำคัญเหนือ TDD: การทดสอบการตั้งชื่อ (มั่นใจ / ควร) และการทดสอบการยอมรับ ฉันควรติดตาม TDD ในระหว่างการพัฒนาโดย BDD หรือไม่ ถ้าใช่จะทำการตั้งชื่อการทดสอบหน่วย TDD ของฉันในแบบเดียวกันให้แน่ใจว่า / ควรมีสไตล์?

BDD เพิ่มรอบรอบวัฏจักร TDD

ดังนั้นคุณเริ่มต้นด้วยพฤติกรรมและปล่อยให้การทดสอบของคุณขับเคลื่อนจากนั้นให้การทดสอบขับเคลื่อนการพัฒนา โดยหลักการแล้ว BDD นั้นได้รับการขับเคลื่อนด้วยการทดสอบการยอมรับบางประเภท แต่ไม่จำเป็นต้องใช้ 100% ตราบใดที่คุณมีพฤติกรรมที่กำหนดไว้คุณก็โอเค

สมมุติว่าคุณกำลังเขียนหน้าเข้าสู่ระบบ

เริ่มต้นด้วยเส้นทางแห่งความสุข:

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

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

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

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

ดังนั้นถึงเวลาที่จะเปลี่ยนเป็นวัฏจักร TDD เพื่อให้การทำงานนั้น

ไม่ว่าคุณจะเขียน BDD หรือไม่ก็ตามการทดสอบของคุณควรตั้งชื่อเป็นไวยากรณ์ทั่วไป หนึ่งในปัญหาที่พบบ่อยที่สุดคือไวยากรณ์ "ควร" ที่คุณอธิบายไว้

เขียนทดสอบ: ShouldAcceptValidDetails ผ่านวงจร Red-Green-Refactor จนกว่าคุณจะพอใจ ตอนนี้เราผ่านการทดสอบพฤติกรรมหรือไม่? ถ้าไม่เขียนการทดสอบอื่น: ShouldRedirectToUserDefaultPage Red-Green-Refactor จนกว่าคุณจะมีความสุข ซักล้างซ้ำจนกว่าคุณจะปฏิบัติตามเกณฑ์ที่กำหนดไว้ในพฤติกรรม

จากนั้นเราก็ไปยังพฤติกรรมต่อไป

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

ตอนนี้คุณไม่ควรยึดเอาสิ่งนี้ไว้เพื่อผ่านพฤติกรรมก่อนหน้านี้ของคุณ คุณควรทดสอบนี้ไม่สำเร็จ ดังนั้นกลับลงไปที่รอบ TDD ของคุณ

และจนกว่าคุณจะมีหน้าของคุณ

ขอแนะนำRspec Bookสำหรับการเรียนรู้เพิ่มเติมเกี่ยวกับ BDD และ TDD แม้ว่าคุณจะไม่ใช่นักพัฒนา Ruby

ความเข้าใจของฉันเกี่ยวกับเรื่องนี้:

• BDD เริ่มเป็น rebranding ของ TDD เพื่อให้ความสำคัญกับพฤติกรรมที่ชัดเจนยิ่งขึ้น
• มันให้การสนับสนุนที่เป็นทางการมากขึ้น (DSL และเครื่องมือ) สำหรับการมุ่งเน้นไปที่พฤติกรรมและข้อมูลจำเพาะที่สามารถดำเนินการได้
• สามารถมองเห็น BDD ในฐานะ superset ของ TDD ได้ มันได้เติบโตขึ้นเมื่อเวลาผ่านไปเพื่อรวมด้านความต้องการของสิ่งต่าง ๆ มากขึ้น แต่ก็ยังด้านกระบวนการพัฒนาเป็นส่วนหลักของมัน

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

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

จาก http://www.metesreau.com/ncraft-workshop/

Gherkin ร่วมกับเครื่องมือเช่น Cucumber และ SpecFlow จัดเตรียมวิธีการเขียนข้อกำหนดคุณลักษณะระดับสูงเหล่านั้นแล้วเชื่อมโยงเข้ากับรหัสที่เรียกใช้รหัสแอปพลิเคชัน ฉันจะยืนยันว่านี่เป็นที่ BDD อาจ 'รู้สึก' แตกต่างจาก TDD แต่จริงๆแล้วมันยังคงทำสิ่งเดียวกันเพียงแค่มีการสนับสนุนเครื่องมือเพิ่มเติมและ DSL ค่อนข้างใกล้เคียงกับ 'ดั้งเดิม' TDD กำลังใช้เครื่องมือเช่น rspec, nspec, spock สิ่งเหล่านี้รู้สึกเหมือนเป็นกระบวนการเดียวกับที่คุณทำใน 'ดั้งเดิม' TDD แต่ด้วยภาษาที่เน้นพฤติกรรมมากขึ้น

ในBDD ในการดำเนินการโดย John Ferguson Smart (แนะนำเป็นอย่างยิ่ง) เขาสนับสนุนวิธี double loop โดยเริ่มจาก jBehave ที่สเปคที่สามารถใช้งานได้ระดับนอกจากนั้นก็วางเครื่องมือเช่น Spock สำหรับสเปคระดับต่ำ

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

อีกส่วนหนึ่งของ BDD ในขณะนี้ซึ่งเป็นที่ที่มันกลายเป็นสิ่งที่รวม TDD อย่างแท้จริงเป็นส่วนหนึ่งของกระบวนการที่มีขนาดใหญ่กว่าคือบิตและชิ้นส่วนที่ต้องการ แนวคิดเช่นการฉีดคุณสมบัติการแมปอิมแพ็คและตัวเลือกจริงเป็นส่วนหนึ่งของด้านนี้

หาคำตอบได้บัญญัติเกี่ยวกับเรื่องนี้มันอาจจะดีที่สุดที่จะไปแดนนอร์ทอีกครั้ง หากทีมของคุณคือนักพัฒนาทั้งหมด BDD = TDD หากทีมของคุณเกี่ยวข้องกับผู้มีส่วนได้ส่วนเสียทั้งหมด BDD นั้นใกล้เคียงกับ XP มากขึ้นโดย TDD เป็นส่วนหนึ่งของมัน

ความสัมพันธ์ของ BDD และ TDD คืออะไร?

พวกเขาเป็นสิ่งเดียวกัน

จากสิ่งที่ฉันเข้าใจ BDD เพิ่มสองสิ่งสำคัญเหนือ TDD: การทดสอบการตั้งชื่อ (มั่นใจ / ควร)

นั่นไม่ใช่สิ่งที่ BDD "เพิ่ม" มันเป็นเพียงการประชุมที่แตกต่างกันซึ่งมีไว้เพื่อให้ง่ายต่อการสอนและเข้าใจ TDD

คนที่สร้าง BDD นั้นล้วน แต่สอน TDD และพวกเขาสังเกตเห็นว่าสิ่งที่ยากที่สุดที่จะเข้าใจคือ TDD นั้นไม่มีอะไรเกี่ยวข้องกับการทดสอบเลย เมื่อนักเรียนข้ามอุปสรรค์นั้นไปได้ง่ายกว่ามากสำหรับพวกเขา แต่มันยากมากที่จะหย่าตัวเองจากการคิดถึงการทดสอบเมื่อคำว่า "ทดสอบ" (หรือคำศัพท์ที่เกี่ยวข้องเช่น "ยืนยัน") ปรากฏขึ้นจริงทุกที่ทุกที่ดังนั้นพวกเขาจึงสลับบางคำไป

แต่มันเป็นเพียงคำพูด! นอกจากนี้ไม่มีความแตกต่างที่เกิดขึ้นจริงระหว่าง TDD และ BDD

และแบบทดสอบการยอมรับ

การทดสอบการยอมรับนั้นมีความสำคัญเป็นส่วนหนึ่งของ TDD เช่นเดียวกับ BDD อีกครั้ง: ไม่มีความแตกต่างระหว่าง TDD และ BDD: TDD ถูกต้องคือ BDD, BDD คือ TDD ทำถูกต้อง