มีหลักฐานยากของ ROI ของการทดสอบหน่วยหรือไม่?


127

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

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

ที่ไหนคือหลักฐานที่ยากที่จะโน้มน้าวให้ฆราวาสเชื่อว่าการทดสอบหน่วยนั้นคุ้มค่ากับความพยายาม?

คำตอบ:


98

ใช่. นี่คือลิงก์ไปยังการศึกษาของ Boby George และ Laurie Williams ที่ NCST และอีกเรื่องหนึ่งโดย Nagappan et al ฉันมั่นใจว่ามีมากกว่านี้ สิ่งพิมพ์ของดร. วิลเลียมส์เกี่ยวกับการทดสอบอาจเป็นจุดเริ่มต้นที่ดีในการค้นหาสิ่งเหล่านี้

[แก้ไข] เอกสารสองฉบับด้านบนอ้างอิงเฉพาะ TDD และแสดงเวลาในการพัฒนาครั้งแรกเพิ่มขึ้น 15-35% หลังจากใช้ TDD แต่ข้อบกพร่องก่อนวางจำหน่ายลดลง 40-90% หากคุณไม่สามารถรับเวอร์ชันข้อความเต็มได้ฉันขอแนะนำให้ใช้Google Scholarเพื่อดูว่าคุณสามารถหาเวอร์ชันที่เผยแพร่ต่อสาธารณะได้หรือไม่


14
การศึกษาครั้งแรกเปรียบเทียบ Agile + TDD กับโครงการ Waterfall ผลลัพธ์จะมีความเกี่ยวข้องมากกว่าหากเปรียบเทียบทีม Agile สองทีม การศึกษาครั้งที่สองกล่าวถึงการศึกษาอื่น ๆ ที่พบว่ามีโบนัสคุณภาพเพียงเล็กน้อยหรือไม่มีเลยสำหรับโครงการ TDD และเมื่อคุณเปรียบเทียบการประมาณการของผู้บริหารเกี่ยวกับช่วงเวลาพิเศษที่จำเป็นสำหรับ TDD จะมีค่าประมาณที่สูงกว่าอย่างมีนัยสำคัญสำหรับทั้งสองทีมที่มีความเชี่ยวชาญด้านโดเมนสูง แต่พวกเขายังมีขอบเขตการทดสอบที่ต่ำกว่า 20% นี่เป็นการยืนยันประสบการณ์ของตัวเองฉันพบว่าความมั่นใจมีความสำคัญมากกว่าในระบบที่ฉันยังไม่เคยทำงานด้วยในขณะที่การทดสอบเป็นอุปสรรคสำหรับสิ่งอื่น ๆ
LearnCocos2D

การศึกษาทั้งสองไม่ได้เปรียบเทียบรูปแบบกระบวนการเปรียบเทียบกับการเปลี่ยนแปลง testmethofology เท่านั้น นั่นคือการใช้เวลาที่ใช้กับ UT นั้นดีกว่าจริงๆเช่น การทดสอบระบบ ตามที่กล่าวมาอาจเป็นเช่นกัน "ถ้าเราทดสอบอย่างชาญฉลาดจะช่วยได้"
Rune FS

1
แล้วจะเกิดอะไรขึ้นถ้าค่าใช้จ่ายในการแก้ไขข้อบกพร่องหลังการเผยแพร่คือ 0.01% ของการพัฒนาทั้งหมด? TDD จะเป็นการลงทุนที่แย่มากในกรณีนั้น และถ้าข้อบกพร่องมีน้อย? % s เหล่านี้ไม่มีความหมายหากไม่มีบริบท เพื่อความเป็นธรรมฉันยังไม่ได้อ่านการศึกษาทั้งหมด แต่เนื่องจากว่าโพสต์ของคุณมีประโยชน์ (ลิงก์ที่ดี) แต่ไม่ได้ตอบคำถามเกี่ยวกับ ROI, IMO
Instine

1
@Instine โชคดี (?) มีหลักฐานที่ดีว่าไม่ใช่กรณีนี้ การแก้ไขข้อบกพร่องหลังการเผยแพร่มีราคาแพงกว่าข้อบกพร่องที่พบในช่วงต้นของการพัฒนาอย่างมาก (ซึ่งเป็นสิ่งที่ TDD ทำ) ในบริบทดังกล่าวค่าใช้จ่าย 0.01% ของการพัฒนาทั้งหมดสำหรับข้อบกพร่องหลังการเผยแพร่ทั้งหมดดูเหมือนจะไม่น่าเป็นไปได้ (สำหรับรายละเอียดโปรดดูCode Completeโดยเฉพาะ Boehm & al. ,“ การทำความเข้าใจและควบคุมต้นทุนซอฟต์แวร์”, IEEE Trans Softw Eng (1988))
Konrad Rudolph

อาจเป็นที่น่าสังเกตว่าการศึกษาครั้งแรกมีตัวอย่างขนาดโปรแกรมเมอร์ 24 คน (ทำงานเป็นคู่ดังนั้น 12 ทีม) ฉันไม่แน่ใจว่าขนาดตัวอย่างที่ถูกต้องทางสถิติจะเป็นเท่าใด แต่ดูเหมือนว่าจะต่ำ บางทีอาจมีคนอื่นรู้?
Zachary Yates

29

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

ทำไม?

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

การเรียนรู้กรอบใช้เวลาน้อยมาก

การเขียนข้อสอบเพียงข้อเดียวใช้เวลาน้อยมาก

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

นั่นคือทั้งหมดที่ต้องใช้ ไม่มีใครต้องรู้ว่าคุณกำลังทำอยู่ แค่ทำมัน.


9
ตัวนับถั่วไม่สามารถบอกการทดสอบหน่วยจากส่วนที่เหลือของรหัสได้ว่าชีวิตของพวกเขาขึ้นอยู่กับมันหรือไม่ ฉันสนับสนุนคำแนะนำที่จะทำมัน มีข้อแม้อย่างหนึ่ง: หากคุณไม่ได้อยู่คนเดียวคุณต้องให้เพื่อนนักพัฒนาของคุณยอมรับแนวทางปฏิบัตินี้ มิฉะนั้นพวกเขาจะทำลายการทดสอบของคุณโดยไม่ได้ตั้งใจ
Thomas Eyde

แค่ทำมันและอย่าบอกพวกเขาและขายความคิดให้กับวิทยาลัยของคุณในช่วงพักดื่มกาแฟ ;-)
โยฮัน

3
เพราะคุณจะถูกไล่ออกเมื่อคุณไม่ถึงกำหนดเวลาของคุณอย่างสม่ำเสมอ?
Andrew

3
@Neko: การทดสอบหน่วยไม่ได้เพิ่ม "ค่าใช้จ่ายเล็กน้อย" พวกเขาลดภาระงานโดยรวมโดยการป้องกันไม่ให้เกิดข้อผิดพลาดโง่ ๆ มากมาย งานไม่เติบโต เพียงแค่เปลี่ยนธรรมชาติจากรหัสที่ไม่ดีไปเป็นการทดสอบหน่วยที่ดีและรหัสที่ดี
ล็อตต์

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

16

ฉันใช้วิธีอื่นในการนี้:

คุณมั่นใจอะไรว่ารหัสของคุณถูกต้อง? หรือว่ามันไม่ทำลายสมมติฐาน X เมื่อมีคนในทีมของคุณเปลี่ยน func1 ()? หากไม่มีการทดสอบหน่วยทำให้คุณ 'ซื่อสัตย์' ฉันไม่แน่ใจว่าคุณมีความมั่นใจมากนัก

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

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

นี่คือที่ที่จ่ายเอง: 1) คุณมั่นใจในรหัสของคุณและ 2) คุณพบปัญหาเร็วกว่าที่คุณทำ คุณไม่มีคนถาม QA พูดว่า "เดี๋ยวก่อนคุณไม่ได้รบกวนการตรวจสอบขอบเขตฟังก์ชัน xyz () ใช่ไหม เขาไม่พบข้อบกพร่องนั้นเพราะคุณพบเมื่อเดือนก่อนซึ่งเป็นสิ่งที่ดีสำหรับ เขาดีสำหรับคุณดีสำหรับ บริษัท และดีสำหรับลูกค้า

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


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

เห็นด้วยโดยสิ้นเชิงเกี่ยวกับการทดสอบหน่วยบังคับให้คุณต้องคิดมากขึ้นเกี่ยวกับการออกแบบและความถูกต้องของคุณมากกว่าการใช้รหัสโดยประมาท
chakrit

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

10

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

Unit Testing หรือ Test Driven Development (TDD) เป็นเทคนิคการออกแบบไม่ใช่เทคนิคการทดสอบ โค้ดที่ทดสอบเป็นลายลักษณ์อักษรมีลักษณะแตกต่างอย่างสิ้นเชิงกับโค้ดที่ไม่ใช่

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

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

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


13
ได้ยินได้ยิน :) หลักฐานที่ยากมากมายสำหรับ TDD ยังมาจากทีมงานที่มีประสบการณ์มากซึ่งได้รับผลลัพธ์ที่ดีอยู่แล้ว TDD เพียงแค่ปรับปรุงผลลัพธ์ของพวกเขาแทนที่จะสร้างขึ้นมาจากอากาศที่เบาบาง ROI ที่แท้จริงคือการจ้างนักเขียนโค้ดที่เหมาะสมและปล่อยให้พวกเขาตัดสินใจว่าจะทำสิ่งต่างๆอย่างไร
workmad3

"เป็นธุรกิจของเคาน์เตอร์ถั่วเพื่อกำหนดวิธีการทำงานของบุคลากรทางเทคนิค" -> การตัดสินใจทางธุรกิจทั้งหมดลงที่เงิน ยังคงเป็นคำตอบที่ดี +1
jcollum

@jcollum แต่วิธีการทำงานของคุณไม่มีส่วนเกี่ยวข้องกับเงินและหากคุณต้องการให้โดมมีความรับผิดชอบคุณปล่อยให้พวกเขาตัดสินใจว่าพวกเขาจะทำสิ่งที่คุณถามพวกเขาอย่างไร
Rune FS

TDD ไม่ใช่เทคนิคการออกแบบ แต่เป็นเพียงเทคนิคการเข้ารหัส blog.ploeh.dk/2010/12/22/TheTDDA โพสต์ผู้แสดงความคิดเห็นจำนวนมากไม่เห็นด้วยที่ TDD เกี่ยวข้องกับการปรับโครงสร้าง (ซึ่งเป็นเทคนิคการออกแบบ) แต่การปรับโครงสร้างใหม่ไม่ได้หมายความถึง TDD เราสามารถ refactor โดยไม่ต้องทดสอบการ refactoring ที่ซับซ้อนขนาดใหญ่มีผลต่อการทดสอบหน่วยอยู่ดีเช่นการทดสอบจำเป็นต้อง refactor ด้วยดังนั้นจึงอาจกลายเป็นสีเขียวที่ไม่ถูกต้อง / เป็นเท็จได้เช่นกัน การปรับโครงสร้างใหม่ที่ง่ายกว่าหลายอย่างไม่ส่งผลต่อการทดสอบ แต่ความเสี่ยงของข้อผิดพลาดต่ำกว่า - เนื่องจากการปรับโครงสร้างใหม่นั้นง่าย
KolA

@KolA ดีด้วยการไตร่ตรองของ 10.5 ปีหลังจากคำตอบนี้ฉันอาจพูดได้ว่ามันเป็นการป้องกันมากขึ้นในวันนี้ แต่ก็ยัง: ฉันไม่เถียงว่า TDD เป็นเทคนิคการออกแบบเดียวที่คุณต้องการและ Mark ก็เปิดขึ้นด้วยความเป็นเทคนิคการออกแบบที่ดีก่อนที่จะสรุปว่ามันไม่มีเลย ฉันรู้สึกไม่สบายใจความเห็นของเขาและบอกว่ามันจะต้องไม่เป็นเพียงเทคนิคการออกแบบ ทุกรหัสที่ฉันเคยเขียน TDD ดูแตกต่างจากรหัสที่ฉันเขียนโดยไม่มี ฉันเรียกสิ่งนั้นว่าเป็นผลมาจากการออกแบบ ฉันทำงานได้ดีที่สุดกับไวท์บอร์ดการอภิปรายและเครื่องมืออื่น ๆ นอกเหนือจาก TDD แต่ขอบคุณสำหรับลิงค์
Olaf Kock

6

หากคุณสนใจในหลักฐานเกี่ยวกับการทดสอบหน่วยนี่เป็นบทความที่ได้รับการค้นคว้าและไตร่ตรองมาเป็นอย่างดี:

ทำไมการทดสอบหน่วยส่วนใหญ่จึงเป็นของเสียโดย James O Coplien (กูรูแบบลีนและคล่องตัว)


6

ข้อมูลเพิ่มเติมเกี่ยวกับ TDD มากกว่าการทดสอบหน่วยอย่างเคร่งครัดนี่คือลิงก์ไปยังการปรับปรุงคุณภาพอย่างแท้จริงผ่านการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ: ผลลัพธ์และประสบการณ์ของเอกสารของทีมอุตสาหกรรมสี่ชิ้นโดย Nagappan, E. Michael Maximilien, Thirumalesh Bhat และ Laurie Williams บทความที่เผยแพร่โดยกลุ่ม Microsoft Empirical Software Engineering and Measurement (ESM) และได้กล่าวถึงแล้วที่นี่

ทีมงานพบว่าทีม TDD ผลิตโค้ดที่อยู่ระหว่าง 60% ถึง 90% ได้ดีกว่า (ในแง่ของความหนาแน่นของข้อบกพร่อง) มากกว่าทีมที่ไม่ใช่ TDD อย่างไรก็ตามทีม TDD ใช้เวลาระหว่าง 15% ถึง 35% ในการทำโครงการให้เสร็จ


5

นี่เป็นการอ่านที่ยอดเยี่ยมและสนุกสนานเกี่ยวกับผู้ชายที่เปลี่ยน บริษัท จากภายใน ไม่ จำกัด เฉพาะ TDD http://jamesshore.com/Change-Diary/โปรดทราบว่าเขาไม่ได้ชักชวนพวก "เคาน์เตอร์ถั่ว" มาระยะหนึ่งแล้วและทำ "กลยุทธ์แบบกองโจร" แทน


ลิงค์ดูน่าสนใจ ... ควรค่าแก่การตรวจสอบเรื่องการเปลี่ยนแปลงกระบวนการทำงานขององค์กร ...
พาสตี้ที่น่ารังเกียจ

5

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

บทนำของบรรณาธิการรับเชิญ: TDD - ศิลปะแห่งการเขียนโปรแกรมที่กล้าหาญ [ ลิงค์ ]

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

ตารางที่ 1. บทสรุปของการศึกษาเชิงประจักษ์ของการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ: ผู้เข้าร่วมในอุตสาหกรรม *

https://www.computer.org/cms/Computer.org/dl/mags/so/2007/03/figures/s3024t1.gif

ตารางที่ 2. สรุปผลการศึกษาเชิงประจักษ์ที่เลือกของ TDD: ผู้เข้าร่วมทางวิชาการ *

ป้อนคำอธิบายภาพที่นี่

ผลของการพัฒนาแบบทดสอบต่อคุณภาพและผลผลิตภายนอก: การวิเคราะห์เมตาดาต้า [ ลิงค์ ]

บทคัดย่อ:

เอกสารนี้ให้การวิเคราะห์อภิมานอย่างเป็นระบบของการศึกษา 27 เรื่องที่ตรวจสอบผลกระทบของ Test-Driven Development (TDD) ต่อคุณภาพและผลผลิตของรหัสภายนอก

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

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


4

มี บริษัท ขนาดใหญ่บางแห่งที่ต้องการให้คุณใช้การทดสอบหน่วย แต่ถ้าคุณเป็น บริษัท ขนาดเล็กทำไมต้องเลียนแบบ บริษัท ขนาดใหญ่?

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

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

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

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

ฉันเพิ่งเริ่มใช้เมื่อใดก็ตามที่ฉันมีสิ่งใหม่ ๆ ที่จะเขียน มีคำพูดเก่า ๆ ที่ค่อนข้างยากสำหรับฉันที่จะแปลเป็นภาษาอังกฤษ แต่:

เริ่มต้นด้วยสิ่งที่เรียบง่ายโดยที่คุณไม่สังเกตว่าคุณทำมัน เมื่อฝึกวิ่งมาราธอนให้เริ่มด้วยการเดิน 9 เมตรและวิ่ง 1 เมตรทำซ้ำ


ดังนั้นฉันควรทำอย่างไร รับประกันว่าจะได้ผลและไม่สำคัญว่าจะไม่มีใครทำกับฉัน?
กา

ที่จริงแล้วนี่คือการทดสอบโจเอล: joelonsoftware.com/articles/fog0000000043.html สำหรับฉันฟังดูแล้วคุณอาจมีปัญหามากกว่าการขาดการศึกษารางวัลโนเบลเรื่องการทดสอบหน่วย
Jonke

4

มีสถิติที่พิสูจน์ได้ว่าการแก้ไขข้อบกพร่องที่พบในการทดสอบหน่วย / การรวมมีค่าใช้จ่ายน้อยกว่าการแก้ไขเมื่ออยู่ในระบบถ่ายทอดสดหลายเท่า (อ้างอิงจากการตรวจสอบโครงการในชีวิตจริงหลายพันโครงการ)

แก้ไข : ตัวอย่างเช่นตามที่ระบุไว้ในหนังสือ " Code Complete " รายงานเกี่ยวกับการศึกษาดังกล่าว (ย่อหน้าที่ 20.3 "ประสิทธิผลสัมพัทธ์ของเทคนิคคุณภาพ") แต่ยังมีงานวิจัยส่วนตัวในสาขาการให้คำปรึกษาที่พิสูจน์ได้เช่นกัน


1
เนื้อหานี้ครอบคลุมอยู่ในCode Completeของ Steve McConnell ซึ่งเป็นหนังสือที่คุณอาจต้องการมีไว้บนชั้นหนังสือด้วยเหตุผลอื่น ๆ
Robert Rossney

ไม่เกี่ยวข้องกับวิธีการทดสอบ แต่เมื่ออยู่ในกระบวนการจะมีการรายงานข้อผิดพลาดและต่อไปจะใช้เวลาในการค้นหาข้อบกพร่องในข้อกำหนดได้ดีขึ้นเนื่องจากค่าใช้จ่ายในการแก้ไขเมื่อพบเมื่อทำการพัฒนาจะมีรายงานว่าแพงมากถึง 1,000 เท่า (ก ปัจจัย 10 ต่อระยะการพัฒนา)
รูน FS

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

0

ฉันมีจุดข้อมูลชุดเดียว - จากประสบการณ์ที่ขายฉันในการทดสอบหน่วย

หลายดวงที่ผ่านมาฉันเป็นบัณฑิตใหม่ที่ทำงานในโครงการ VB6 ขนาดใหญ่และมีโอกาสเขียนโค้ดกระบวนงานที่เก็บไว้เป็นจำนวนมาก ในระบบย่อยฉันกำลังเขียนมันประกอบด้วยประมาณ 1/4 ของฐานรหัสทั้งหมด - ประมาณ 13,000 LOC จาก 50K หรือมากกว่านั้น

ฉันเขียนชุดการทดสอบหน่วยสำหรับกระบวนงานที่จัดเก็บไว้ แต่การทดสอบหน่วยรหัส VB6 UI นั้นไม่สามารถทำได้หากไม่มีเครื่องมือเช่น Rational Robot อย่างน้อยมันก็ไม่ได้ย้อนกลับไป

สถิติจาก QA บนชิ้นส่วนพบว่ามีข้อบกพร่องประมาณ 40 หรือ 50 ข้อในระบบย่อยทั้งหมดซึ่งทั้งสองมีต้นกำเนิดมาจากขั้นตอนการจัดเก็บ นั่นคือข้อบกพร่องหนึ่งข้อต่อรหัส 6,500 บรรทัดเทียบกับ 1 ต่อ 1,000-1,200 หรือมากกว่านั้นทั่วทั้งชิ้น โปรดทราบด้วยว่ารหัส VB6 ประมาณ 2/3 เป็นรหัสต้นแบบสำหรับการจัดการข้อผิดพลาดและการบันทึกซึ่งจะเหมือนกันในทุกขั้นตอน

โดยไม่ต้องโบกมือมากเกินไปคุณสามารถระบุอย่างน้อยการปรับปรุงลำดับความสำคัญของอัตราความบกพร่องในการทดสอบหน่วย

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.