อะไรคือความแตกต่างหลักระหว่าง TDD และ BDD? [ปิด]

การทดสอบขับเคลื่อนการพัฒนาเป็นเรื่องที่น่าตื่นเต้นในชุมชน. NET ในช่วงสองสามปีที่ผ่านมา เมื่อเร็ว ๆ นี้ฉันได้ยินเสียงบ่นในชุมชน ALT.NET เกี่ยวกับ BDD มันคืออะไร? อะไรทำให้แตกต่างจาก TDD?

ผมเข้าใจ BDD จะมีมากขึ้นเกี่ยวกับสเปคกว่าการทดสอบ มันเชื่อมโยงกับ Domain Driven Design (คุณไม่ชอบคำย่อ * DD เหล่านี้หรือไม่)

มีการเชื่อมโยงกับวิธีหนึ่งในการเขียนเรื่องราวของผู้ใช้รวมถึงการทดสอบระดับสูง ตัวอย่างโดยTom ten Thij :

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

Scenario: User uses wrong password

  Given a username 'jdoe'
  And a password 'letmein'

  When the user logs in with username and password

  Then the login form should be shown again

(ในบทความของเขา Tom ดำเนินการตามข้อกำหนดการทดสอบนี้โดยตรงใน Ruby)

สมเด็จพระสันตะปาปาของ BDD เป็นแดนนอร์ท คุณจะพบคำแนะนำที่ยอดเยี่ยมในบทความแนะนำ BDDของเขา

คุณจะพบการเปรียบเทียบ BDD และ TDD ในวิดีโอนี้ นอกจากนี้ยังมีความเห็นเกี่ยวกับ BDD ว่า "TDD done right" โดยJeremy D. Miller

อัปเดตวันที่ 25 มีนาคม 2013

วิดีโอด้านบนหายไปช่วงหนึ่ง นี่คือหนึ่งเมื่อเร็ว ๆ นี้โดยลีเวลลีฟัลโคBDD VS TDD (อธิบาย) ฉันพบว่าคำอธิบายของเขาชัดเจนและตรงประเด็น

สำหรับฉันความแตกต่างหลักระหว่าง BDD และ TDD คือโฟกัสและถ้อยคำ และคำพูดเป็นสิ่งสำคัญสำหรับการสื่อสารเจตนาของคุณ

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

BDD มุ่งเน้นไปที่พฤติกรรมและข้อกำหนดและจิตใจน้ำตกจึงฟุ้งซ่าน ดังนั้น BDD จึงเข้าใจได้ง่ายขึ้นว่าเป็นการฝึกฝนการออกแบบไม่ใช่เป็นการทดสอบ

BDD ดูเหมือนจะมีสองประเภท

ประการแรกคือรูปแบบดั้งเดิมที่ Dan North กล่าวถึงและก่อให้เกิดการสร้างกรอบสไตล์ xBehave สำหรับฉันแล้วสไตล์นี้ใช้เป็นหลักสำหรับการทดสอบการยอมรับหรือข้อมูลจำเพาะกับออบเจ็กต์โดเมน

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

นอกจากนี้ยังมีกลุ่ม BDD ซึ่งคุณอาจพบว่ามีประโยชน์:

http://groups.google.com/group/behaviordrivendevelopment/

Test-Driven Developmentเป็นวิธีการพัฒนาซอฟต์แวร์ที่ต้องทดสอบก่อนซึ่งหมายความว่าจะต้องมีการเขียนโค้ดทดสอบก่อนที่จะเขียนโค้ดจริงที่จะทดสอบ ในคำพูดของ Kent Beck:

รูปแบบในที่นี้คือการเขียนโค้ดสองสามบรรทัดจากนั้นจึงเป็นการทดสอบที่ควรรันหรือดีกว่านั้นเพื่อเขียนการทดสอบที่ไม่ทำงานจากนั้นเขียนโค้ดที่จะทำให้มันทำงาน

หลังจากหาวิธีเขียนโค้ดชิ้นเล็ก ๆ แล้วตอนนี้แทนที่จะเขียนโค้ดเพียงอย่างเดียวเราต้องการรับคำติชมทันทีและฝึกฝน "โค้ดหน่อยทดสอบหน่อยโค้ดหน่อยทดสอบนิดหน่อย" ดังนั้นเราจึงเขียนแบบทดสอบทันที

ดังนั้น TDD จึงเป็นวิธีการทางเทคนิคระดับต่ำที่โปรแกรมเมอร์ใช้ในการสร้างโค้ดที่สะอาดและใช้ได้ผล

Behavior-Driven Developmentเป็นวิธีการที่สร้างขึ้นโดยใช้ TDD แต่พัฒนาไปสู่กระบวนการที่ไม่เกี่ยวข้องกับเฉพาะโปรแกรมเมอร์และผู้ทดสอบเท่านั้น แต่จะเกี่ยวข้องกับทั้งทีมและผู้มีส่วนได้ส่วนเสียที่สำคัญทั้งหมดทั้งทางเทคนิคและทางเทคนิค BDD เริ่มต้นจากคำถามง่ายๆสองสามข้อที่ TDD ตอบได้ไม่ดี: ฉันควรเขียนข้อสอบมากแค่ไหน? ฉันควรทดสอบอะไร - และอะไรไม่ควร? การทดสอบข้อใดที่ฉันเขียนจะมีความสำคัญต่อธุรกิจหรือต่อคุณภาพโดยรวมของผลิตภัณฑ์และข้อใดเป็นเพียงวิศวกรรมขั้นสูงของฉัน

อย่างที่คุณเห็นคำถามดังกล่าวต้องการการทำงานร่วมกันระหว่างเทคโนโลยีและธุรกิจ ผู้มีส่วนได้ส่วนเสียทางธุรกิจและผู้เชี่ยวชาญด้านโดเมนมักจะบอกวิศวกรได้ว่าการทดสอบแบบใดที่ดูเหมือนจะมีประโยชน์ แต่ก็ต่อเมื่อการทดสอบนั้นเป็นการทดสอบระดับสูงที่เกี่ยวข้องกับประเด็นสำคัญทางธุรกิจ BDD เรียกการทดสอบแบบธุรกิจเช่นนี้ว่า "ตัวอย่าง" ในขณะที่ "บอกตัวอย่างว่าคุณลักษณะนี้ควรทำงานอย่างไร" และขอสงวนคำว่า "ทดสอบ" สำหรับการตรวจสอบทางเทคนิคระดับต่ำเช่นการตรวจสอบข้อมูลหรือการทดสอบการรวม API ส่วนที่สำคัญคือในขณะที่การทดสอบเท่านั้นสามารถสร้างขึ้นโดยโปรแกรมเมอร์และทดสอบตัวอย่างที่สามารถเก็บรวบรวมและวิเคราะห์โดยการส่งมอบทั้งทีมโดยนักออกแบบนักวิเคราะห์และอื่น ๆ

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

ตอนนี้การสนทนากับผู้เชี่ยวชาญด้านธุรกิจและโดเมนฟังดูดี แต่เราทุกคนรู้ดีว่าการสนทนานั้นมักจะจบลงอย่างไรในทางปฏิบัติ ฉันเริ่มต้นการเดินทางด้วยเทคโนโลยีในฐานะโปรแกรมเมอร์ ในฐานะโปรแกรมเมอร์เราได้รับการสอนให้เขียนโค้ด -อัลกอริทึม, รูปแบบการออกแบบ, นามธรรม หรือถ้าคุณเป็นนักออกแบบคุณจะได้รับการสอนให้ออกแบบ- จัดระเบียบข้อมูลและสร้างอินเทอร์เฟซที่สวยงาม แต่เมื่อเราได้งานระดับเริ่มต้นนายจ้างของเราคาดหวังว่าเราจะ "ส่งมอบคุณค่าให้กับลูกค้า" และในบรรดาลูกค้าเหล่านั้นอาจเป็นตัวอย่างเช่น ... ธนาคาร แต่ฉันไม่รู้อะไรเลยเกี่ยวกับการธนาคารยกเว้นวิธีลดยอดเงินในบัญชีของฉันอย่างมีประสิทธิภาพ ดังนั้นฉันจะต้องแปลสิ่งที่คาดหวังในตัวฉันเป็นรหัส ... ฉันจะต้องสร้างสะพานเชื่อมระหว่างการธนาคารและความเชี่ยวชาญด้านเทคนิคของฉันหากฉันต้องการส่งมอบคุณค่าใด ๆ BDD ช่วยฉันสร้างสะพานดังกล่าวบนรากฐานที่มั่นคงของการสื่อสารที่ลื่นไหลระหว่างทีมจัดส่งและผู้เชี่ยวชาญด้านโดเมน

เรียนรู้เพิ่มเติม

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

หากคุณสนใจที่จะซื้อ“ การเขียนข้อมูลจำเพาะที่ยอดเยี่ยม” คุณสามารถประหยัดได้ 39%ด้วยรหัสโปรโมชั่น39nicieja2 :)

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

BDD ยังใช้เป็นเครื่องมือสื่อสาร เป้าหมายคือการเขียนข้อกำหนดปฏิบัติการซึ่งผู้เชี่ยวชาญด้านโดเมนสามารถเข้าใจได้

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

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

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

บทความ Wikipedia มีคำอธิบาย:

การพัฒนาที่ขับเคลื่อนด้วยพฤติกรรม

ไม่ได้ฝึก BDD ด้วยตัวเอง

พิจารณาประโยชน์หลักของ TDD ในการออกแบบ ควรเรียกว่า Test Driven Design BDD เป็นส่วนย่อยของ TDD เรียกว่า Behavior Driven Design

ตอนนี้พิจารณาการนำ TDD - Unit Testing ไปใช้งานที่เป็นที่นิยม โดยทั่วไปหน่วยในการทดสอบหน่วยจะเป็นตรรกะหนึ่งบิตซึ่งเป็นหน่วยงานที่เล็กที่สุดที่คุณสามารถทำได้

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

ฉันจะเพิ่มว่าการทดสอบ BDD เป็นข้อกำหนดในการดำรงชีวิต

BDD ส่วนใหญ่ TDD ทำถูกต้อง อย่างไรก็ตามมีมูลค่าเพิ่มเติมที่ BDD มอบให้ นี่คือลิงค์ที่:

BDD เป็นมากกว่า“ TDD ถูกต้อง”

ไม่มีความแตกต่างระหว่าง TDD และ BDD ยกเว้นว่าคุณจะอ่านการทดสอบของคุณได้ดีขึ้นและคุณสามารถใช้ตามข้อกำหนด หากคุณเขียนข้อกำหนดของคุณด้วยคำเดียวกับที่คุณเขียนการทดสอบ BDD คุณสามารถมาจากลูกค้าของคุณด้วยการทดสอบบางอย่างที่กำหนดไว้พร้อมที่จะเขียนโค้ด

ความแตกต่างระหว่างการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD) และการพัฒนาที่ขับเคลื่อนด้วยพฤติกรรม (BDD)

• BDD มุ่งเน้นไปที่ด้านพฤติกรรมของระบบมากกว่า
  ด้านการนำไปใช้ของระบบที่ TDD มุ่งเน้นไปที่

• BDD ให้ความเข้าใจที่ชัดเจนขึ้นว่าระบบควรทำอย่างไร
  จากมุมมองของผู้พัฒนาและลูกค้า TDD
  ช่วยให้นักพัฒนาเข้าใจถึงสิ่งที่ระบบควรทำเท่านั้น

• BDD ช่วยให้ทั้งผู้พัฒนาและลูกค้าทำงานร่วมกันเพื่อวิเคราะห์ข้อกำหนดที่มีอยู่ในซอร์สโค้ดของระบบ

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

นี่คือภาพรวมด่วน:

• TDD เป็นเพียงขั้นตอนการทดสอบโค้ดก่อนเขียนเท่านั้น!

• DDD คือขั้นตอนการรับแจ้งเกี่ยวกับโดเมนก่อนการแตะรหัสแต่ละรอบ!

• BDD คือการนำ TDD มาใช้ซึ่งนำมาซึ่งบางแง่มุมของ DDD!