มีการใช้ BDD (Behavior Driven Development) ในเกมหรือไม่

ฉันอ่านเกี่ยวกับ BDD - การพัฒนาพฤติกรรมขับเคลื่อนมาระยะหนึ่งแล้วและฉันคิดว่ามันง่ายและมีประโยชน์ในการแปลงคุณสมบัติให้เป็นรหัส ผู้ใช้ BDD มักจะเรียกมันว่า TDD ถูกต้องแล้ว

BDD เป็นเครื่องมือสำหรับการออกแบบซอฟต์แวร์จากภายนอกสู่ภายในจากค่า bussiness (หรือค่าการเล่นเกม) ไปยังรหัส

แดนเหนือแนะนำ BDD

คุณรู้จักแหล่งข้อมูลเกี่ยวกับ BDD และเกมอื่นนอกเหนือจากนี้หรือไม่?

มันอาจจะปลอดภัยที่จะบอกว่า BDD เช่น TDD หรือ (แทรก buzzword-paradigm ที่ทันสมัยในการพัฒนาที่นี่) ถูกนำมาใช้โดยนักพัฒนาเกมบางแห่ง แต่พวกเขาอาจไม่รู้ว่าพวกเขาเป็นหรือไม่ . คำถามคือจริงๆเท่าไหร่ที่พวกเขาใช้มันและวิธีการมากที่พวกเขามีที่จะใช้มันให้มันสำคัญกับคุณ?

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

ในความคิดของฉันไม่ควรจะใช้คำที่คุณใช้ในสตูดิโอ แต่ควรใช้เทคนิคการเพิ่มผลิตผลและกระบวนการพัฒนาที่คุณใช้โดยรวม ฉันพบว่าทีมที่มีประสิทธิภาพมากที่สุดกำลังผสมและจับคู่เทคนิคจาก "buzzword-paradigms" ที่หลากหลายแทนที่จะกระทำอย่างดันทุรังจนถึงหลักคำสอนที่เข้มงวดทุกการศึกษาทางอินเทอร์เน็ตบางอย่างกล่าวว่าประกอบด้วยหนึ่ง buzzword-paradigm

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

ทีมพัฒนาประกอบด้วยมนุษย์ซึ่งไม่ได้เป็นฟันเฟืองแทนกันในเครื่องจักร พวกเขาทำงานเฉพาะบุคคลและเป็นชุดที่ไม่ซ้ำกันของตัวเอง วิธีในการพัฒนาที่มีประสิทธิภาพไม่ได้ทำให้มนุษย์ของคุณงอเข้ากับรูปแบบ {BDD, Agile, AnythingIsNext} แต่จะต้องประเมินอย่างต่อเนื่องว่าทีมมีความคืบหน้าและทำให้เกิดข้อบกพร่องในกระบวนการแทนที่เทคโนโลยีที่เสียหายและเสริมสิ่งต่างๆ การทำงาน กล่าวโดยย่อคือมุ่งเน้นไปที่การจัดส่งชื่อและไม่ได้อยู่ที่ "กำลังคล่องตัว (หรืออะไรก็ตาม)"

ใช่ไหม? อาจจะ. ความคิดเห็นของฉันน่าจะเป็นสิ่งที่ทำให้ซอฟท์แวร์ด้านความบันเทิงโดยทั่วไปแย่ลงแม้ว่ามันจะทำงานได้ดีสำหรับไลบรารี่ระดับต่ำ

แก้ไข: นี่คือเหตุผลบางอย่างสำหรับความคิดเห็นของฉัน

Wikipedia กำหนด BDD เป็นเทคนิคที่"ส่งเสริมการทำงานร่วมกันระหว่างผู้พัฒนา QA และผู้ที่ไม่ใช่ด้านเทคนิคหรือผู้ร่วมธุรกิจในโครงการซอฟต์แวร์"สิ่งนี้ฟังดูเหมือนเป็นความคิดที่ไม่ดีเนื่องจากเกมต่างจากซอฟต์แวร์ส่วนใหญ่เนื่องจากไม่ได้ออกแบบมาเป็นเครื่องมือเพื่อตอบสนองความต้องการเฉพาะสำหรับ 'ผู้เข้าร่วมที่ไม่ใช่ด้านเทคนิคหรือธุรกิจ' แต่เป็นงานที่ออกแบบมาเพื่อความบันเทิง มีการเน้นที่ "พฤติกรรมซอฟต์แวร์ที่ต้องการ" แต่เกมไม่ค่อยมี 'พฤติกรรมซอฟต์แวร์ที่ต้องการ' ยกเว้นในระดับเทคนิค มีข้อดีอย่างแน่นอนในการตรวจสอบส่วนของรหัสนั้น แต่ไม่ใช่กับผู้ใช้ปลายทางเพราะพวกเขาจะไม่เห็นมัน

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

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

นอกจากนี้วิธีการทดสอบครั้งแรกสามารถสร้างความปลอดภัยที่ผิดพลาดและทำให้ผู้คนเชื่อว่าโค้ดดีกว่าที่เป็นจริง

def check_dice_roll_in_range():
    d = new Dice()
    assert(d.roll() between 1 and 6)

class Dice:
    def roll():
        return 4

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

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

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

(หวังว่าจะเป็นคำตอบที่ดีกว่าแม้ว่าคุณจะไม่เห็นด้วยกับคะแนนของฉัน)

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

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

ไปอ่านเกี่ยวกับ "สัญญา" ในหนังสือของ Pragmatic Progammer การทดสอบช่วยให้คุณบรรลุสัญญารหัส รหัสนี้ทำ X และไม่มีอะไรมากไปกว่า X และอย่าคาดหวังว่ามันจะทำอะไรเกี่ยวกับ Y หรือพยายามที่จะปรับให้เข้ากับ Z มันรับประกันความสะอาดของรหัสและคาดหวังว่าทุกคนจะไม่หัวเสีย

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

ในจุดที่ "วิธี" มันขึ้นอยู่กับสภาพแวดล้อมของคุณ ฉันกำลังเขียนเกมจาวาตอนนี้และใช้ robolectric คุณควรพยายาม "คาดหวัง" บางสิ่งอยู่เสมอ ฉันได้ยินมาว่าสายลับ / mocks / stubs นั้นไม่ได้มีประโยชน์เท่าที่ควรเพราะคุณต้องมีความเท่าเทียมกัน แต่บางครั้งคุณไม่มีทางเลือกโดยเฉพาะกับ API คุณสามารถสันนิษฐานได้ว่าอีกด้านหนึ่งของ API นั้นไม่น่ากลัวและเป็นรหัสของคุณที่แย่มาก

ตัวอย่างเช่นคุณกำลังทดสอบการเคลื่อนไหว คุณคาดหวังได้เมื่อกด "Up" ที่ผู้ใช้เลื่อนไปข้างหน้าโดยการวัดบางอย่าง

ตัวอย่างเช่นถ้าคุณกำลังทดสอบการแสดงผลกราฟิก ... ดีไม่ทดสอบที่มากเกินไปเพราะคุณทำอย่างนั้นจริง ๆ ? กรอบการทดสอบที่ดีอาจจัดการส่วนนี้ให้คุณ การไตร่ตรองนั้นไม่สำคัญอย่างยิ่งที่ฉันจะพูดถึงสิ่งต่าง ๆ เหล่านี้ คุณอาจต้องตรวจสอบบัฟเฟอร์ ฯลฯ ฯลฯ ฉันเพียงแค่ตรวจสอบสิ่งที่คุณกำลังทำอยู่ ตัวละครอยู่ที่นี่ตอนนี้เขาอยู่ที่นั่นหลังจากการกระทำบางอย่าง

คุณควรมีฟังก์ชั่นเล็ก ๆ น้อย ๆ / การทดสอบเล็ก ๆ น้อย ๆ และร่วมกันพวกเขาจะรวมถึงสิ่งที่มีประโยชน์

ฉันรู้สึกว่ามีความเข้าใจผิดเกี่ยวกับ BDD คืออะไร BDD ไม่ใช่เทคนิคการทดสอบหรือกระบวนการ BDD เป็นรูปแบบการพัฒนาและกระบวนการ มันไปได้ไกลกว่าการทดสอบและเป็นมากกว่าการเขียนโปรแกรม

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