BDD สามารถปรับขนาดได้สำหรับโครงการขนาดกลางถึงใหญ่หรือไม่?

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

ดังนั้นฉันสงสัยว่า BDD คุ้มค่าหรือไม่ มันแก้ปัญหาที่เทคนิคอื่นไม่ได้หรือไม่!

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

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

มันอาจช่วยให้ตระหนักว่าโฟกัสของ BDD คือการสนทนาการสนทนาBDD เป็นเครื่องมือวิเคราะห์ที่เกิดขึ้นจริงเพื่อให้การทดสอบการถดถอยบางอย่างเป็นผลพลอยได้ที่ดี

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

มีคำแนะนำและเคล็ดลับสองสามข้อที่ฉันสามารถแนะนำเพื่อให้ง่ายขึ้น

หากคุณไม่เคยทำมาก่อนมันจะเปลี่ยนไป

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

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

หากคุณเคยทำมาก่อนมันน่าเบื่อ

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

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

หากมีใครทำมาก่อนการพูดคุยผ่านสถานการณ์สามารถช่วยได้

มีความแตกต่างระหว่างที่เรามีความต้องการเฉพาะโดเมนสิ่งที่ค่อนข้างเข้าใจได้ง่าย ใครบางคนและความไม่แน่นอนที่แท้จริงนั้นอยู่ใกล้ขอบเขตมากกว่าพฤติกรรมที่แท้จริงของระบบ

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

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

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

อ่านเพิ่มเติม

หากคุณสนใจสิ่งนี้ฉันจะเขียนสิ่งที่อาจช่วยได้

BDD ในตัวขนาดใหญ่

Cynefin สำหรับผู้พัฒนาซอฟต์แวร์ซึ่งจะเข้าไปดูรายละเอียดเพิ่มเติมในสามด้านนี้

สไลด์การสอนของฉันซึ่งทั้งหมดเป็นสิ่งที่ดีและมีคำอธิบายประกอบสำหรับคุณและครอบคลุมสแต็กทั้งหมดด้วย

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

ให้ฉันได้สิ่งหนึ่งที่หลีกทาง: การทดสอบกฎเกณฑ์ทางธุรกิจที่ซับซ้อนนั้นยาก คำถามคือคุณต้องการที่จะลองและจดจำสถานการณ์ที่บ้าคลั่งทั้งหมดเมื่อใดก็ตามที่คุณทำการเปลี่ยนแปลงหรือคุณต้องการให้ตาข่ายความปลอดภัยนั้นแจ้งให้คุณทราบเมื่อคุณเสียสเป็ค ใช้เวลาในการเตรียมงานและทำทุกสถานการณ์จดบันทึกและเขียนการทดสอบทั้งหมดในที่สุด

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

BDD เป็นกระบวนการพัฒนาที่อิง TDD (Test Driven Development) นี่คือข้อดีและข้อเสียของ TDD จากประสบการณ์ส่วนตัวของฉัน:

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

จุดด้อย:

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

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