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


24

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

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

ฉันสนใจผลของการทดสอบหน่วยในเวลาและค่าใช้จ่ายในการพัฒนา:

  • เวลาในการเขียนการทดสอบหน่วยเป็นส่วนหนึ่งของกระบวนการพัฒนาจะเพิ่มเวลาเท่าใด
  • เวลาเท่าไรที่จะถูกบันทึกในกิจกรรมการบำรุงรักษา (การทดสอบและการดีบัก) โดยการทดสอบหน่วยที่ดี?

คำตอบ:


25

มีสถิติใดบ้างที่จะใช้เวลานานเท่าใดในการพัฒนาแอปพลิเคชันเมื่อสร้างการทดสอบหน่วยในระหว่างการพัฒนาเทียบกับการเข้ารหัส?

มีงานวิจัยที่น่าสนใจเกี่ยวกับเรื่องนี้ อ่านเอกสารทางเทคนิคต่อไปนี้:

ตระหนักถึงการปรับปรุงคุณภาพด้วยการพัฒนาแบบทดสอบที่ขับเคลื่อน: ผลลัพธ์และประสบการณ์ของทีมอุตสาหกรรมสี่ทีม

เอกสารวิชาการและงานวิจัยอื่น ๆ จากผู้เขียนคนหนึ่งคือNachi Nagappanได้กล่าวถึงที่นี่: http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx

การศึกษาและผลการวิจัยถูกตีพิมพ์ในกระดาษเรื่องการปรับปรุงคุณภาพให้ดีขึ้นผ่านการพัฒนาแบบทดสอบขับเคลื่อน: ผลลัพธ์และประสบการณ์ของทีมอุตสาหกรรมสี่แห่งโดย Nagappan และเพื่อนร่วมงานวิจัย E. Michael Maximilien จากศูนย์วิจัย IBM Almaden; Thirumalesh Bhat หัวหน้าฝ่ายพัฒนาซอฟต์แวร์หลักของ Microsoft; และ Laurie Williams จาก North Carolina State University สิ่งที่ทีมวิจัยพบคือทีม TDD สร้างรหัสที่ดีกว่าในแง่ของความหนาแน่นของข้อบกพร่องกว่า 60 ถึง 90 เปอร์เซ็นต์มากกว่าทีมที่ไม่ใช่ TDD พวกเขาค้นพบว่าทีม TDD ใช้เวลาในการดำเนินการโครงการนานกว่า - 15 ถึง 35 เปอร์เซ็นต์อีกต่อไป

“ ตลอดวงจรการพัฒนา 12 เดือน 35 เปอร์เซ็นต์เป็นอีกสี่เดือนซึ่งมีขนาดใหญ่มาก” Nagappan กล่าว “ อย่างไรก็ตามข้อดีข้อเสียคือคุณลดค่าใช้จ่ายในการบำรุงรักษาหลังการขายลงอย่างมากเนื่องจากคุณภาพของรหัสนั้นดีกว่ามาก การตัดสินใจเหล่านี้คือการตัดสินใจที่ผู้จัดการต้องทำ แต่ตอนนี้พวกเขามีข้อมูลเชิงปริมาณสำหรับการตัดสินใจเหล่านั้นแล้ว”

นอกจากนี้Jason Gormanได้เสนอการทดลองดังกล่าวสำหรับการประชุม Software Craftsmanship Conference ในปีนี้ เขาพยายามทดลองสร้างแอปพลิเคชันเดียวกันโดยใช้ TDD และวิธีการที่ไม่ใช่ TDD และเขาเพิ่ง blogged เกี่ยวกับผลลัพธ์ของเขา :

การทำซ้ำ 3 ครั้งเวลาเฉลี่ยในการทำกะตะโดยไม่ต้องใช้ TDD เท่ากับ 28m 40s เวลาเฉลี่ยกับ TDD คือ 25m 27s หากไม่มี TDD โดยเฉลี่ยแล้วฉันผ่านไป 5.7 ครั้ง (ส่งไปยังการทดสอบการยอมรับ) ด้วย TDD โดยเฉลี่ยฉันทำได้ 1.3 รอบ (ในความพยายามสองครั้งพวกเขาผ่านครั้งแรกหนึ่งครั้งก็ทำได้ 2 ครั้ง)

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

มันจะน่าสนใจที่จะเห็นผลเต็มรูปแบบของการทดลองนี้เมื่อมีคนทำมันมากขึ้น

มีสถิติใดบ้างที่แสดงว่าการบำรุงรักษาลดลงกี่ชั่วโมงเมื่อมีการทดสอบ (ดี) หรือไม่

จากกระดาษขาวด้านบน:

ผลจากกรณีศึกษาระบุว่าความหนาแน่นข้อบกพร่องก่อนวางจำหน่ายของทั้งสี่ผลิตภัณฑ์ลดลงระหว่าง 40% และ 90% เมื่อเทียบกับโครงการที่คล้ายกันซึ่งไม่ได้ใช้วิธีฝึก TDD


ฉันชอบคำตอบนี้ ฉันจะเพิ่มว่าเครื่องมือภาษาและการทดสอบสามารถมีผลกระทบอย่างมากต่อเวลา TDD สำหรับภาษาอย่าง C # ก่อน NCRUNCH ฉันไม่ค่อยตื่นเต้นกับประโยชน์ของ TDD หลังจากเห็นและใช้ NCRUNCH ในมุมมองของฉันแนวโน้มที่จะทำการทดสอบแบบขนานคือคุณรหัสคือการเปลี่ยนแปลงที่สำคัญในประสิทธิภาพของเครื่องมือดังกล่าว การวิจัยในปี 2551 อาจไม่สะท้อนเครื่องมือปัจจุบันและประสิทธิผลของเครื่องมือเหล่านี้
ฟิล soady
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.