มีพื้นที่ที่ TDD ให้ผลตอบแทนการลงทุนสูงและพื้นที่อื่น ๆ ที่ ROI ต่ำมากจนไม่คุ้มกับการติดตามหรือไม่? [ปิด]

31

ทดสอบการพัฒนาขับเคลื่อน ฉันเข้าใจแล้วชอบ

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

development-process tdd

— Phillip Ngan
แหล่งที่มา

1

ต้องค้นหา ROI "Return On Investment" :)

— Songo

คุณได้ตอบคำถามของคุณเองแล้ว: ใช้ตามความเหมาะสม

— jwenting

27

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

แอพที่ฉันทำงานเมื่อไม่นานมานี้เป็น webapps ที่ขับเคลื่อนด้วยข้อมูลซึ่งสร้างขึ้นบน Gui-> Presenter-> BusinessLogic-> สถาปัตยกรรมที่ใช้ Data Layer Layer ชั้นการเข้าถึงข้อมูลของฉันได้รับการทดสอบเหมือนไม่มีใครทำธุรกิจ ชั้นตรรกะทางธุรกิจนั้นผ่านการทดสอบแล้ว ผู้นำเสนอได้รับการทดสอบเฉพาะในพื้นที่ที่มีเสถียรภาพมากขึ้นและ GUI ซึ่งกำลังเปลี่ยนแปลงรายชั่วโมงแทบจะไม่มีการทดสอบ

— Fishtoaster
แหล่งที่มา

7

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

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

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

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

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

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

— Damovisa
แหล่งที่มา

6

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

ฉันคิดว่าการยกเลิกการดีบั๊กสำหรับการทดสอบการเขียนนั้นเป็นการต่อรองที่ดีมาก

— xpmatteo
แหล่งที่มา

3

ที่เดียวที่ TDD ดูดยากจริงๆคือเมื่อทดสอบมุมมองในแอป MVC

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

ฉันชอบ TDD สำหรับการทดสอบของฉันมากมาย แต่มันไม่ได้เป็นเพียงเครื่องมือเดียวในแถบโปรแกรมเมอร์

— แซมซัฟฟรอน
แหล่งที่มา

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

— sara