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

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

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

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

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

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

ทำไม?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

บทคัดย่อ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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