เรากำลังเริ่มต้นผลักดันการครอบคลุมโค้ดในที่ทำงานของฉันและทำให้ฉันคิดว่า .... การครอบคลุมโค้ดมีมากพอเพียงใด

เมื่อไหร่ที่คุณจะไปถึงจุดที่จะได้รับผลตอบแทนจากการครอบคลุมโค้ด? อะไรคือจุดหวานระหว่างความครอบคลุมที่ดีและไม่เพียงพอ มันแตกต่างกันไปตามประเภทของโครงการที่คุณทำ (เช่น WPF, WCF, มือถือ, ASP.NET) (นี่คือคลาส C # ที่เรากำลังเขียน)

เราตั้งเป้าหมายอย่างน้อย 70% ในสิ่งที่สามารถทดสอบได้ง่ายขึ้น (ตัวอย่างโครงสร้างข้อมูลที่ใช้งานได้) เราตั้งเป้าหมาย 90% และบุคคลส่วนใหญ่มีเป้าหมายใกล้เคียง 100% ที่สุดเท่าที่จะทำได้ ในสิ่งที่เกี่ยวข้องกับ WPF และกรอบงานอื่น ๆ ที่ยากต่อการทดสอบเราได้รับความคุ้มครองที่ต่ำกว่ามาก (แทบจะ 70%)

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

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

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

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

ความครอบคลุมคือตัวชี้วัดที่จะเก็บตาบน แต่มันไม่ควรจะเป็นเป้าหมายสูงสุด ฉันเคยเห็น (และเขียนอย่างถูกต้อง!) รหัสความครอบคลุมสูงมากมาย - ความคุ้มครอง 100% (แน่นอนว่า TDD) ยัง:

• ข้อผิดพลาดยังคงเกิดขึ้น
• การออกแบบอาจจะไม่ดี
• คุณสามารถฆ่าตัวตายได้ด้วยการยิงเพื่อเป้าหมายที่กำหนดเอง - เลือกการต่อสู้ของคุณ: p

มี "วิถีแห่ง Testivus" เป็นรายการที่ผมคิดว่ามีความเหมาะสมที่จะอ้างอิงที่นี่ :)

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

ดังนั้นตรวจสอบให้แน่ใจว่าได้ครอบคลุม 100% ของ 20% ที่กำหนดเส้นทางวิกฤตและอย่างน้อย 50% ของที่เหลือ (ตามกราฟการโทร) สิ่งนี้จะทำให้คุณได้รับ (โดยประมาณ) 70% - 75% ความครอบคลุมทั้งหมด แต่แตกต่างกันไป

อย่าเสียเวลาพยายามรับความคุ้มครองรวมกว่า 70% ในขณะที่ออกจากคดีขอบที่สำคัญโดยไม่มีการตรวจสอบ

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

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

ฉันทำงานกับซอฟต์แวร์การบินที่มีความสำคัญอย่างยิ่งซึ่งครอบคลุมการตรวจสอบงบ 100% เหมาะสำหรับระบบที่ไม่สำคัญ สำหรับระบบที่สำคัญยิ่งกว่านั้นเราตรวจสอบความครอบคลุมสาขา / การตัดสินใจและใช้เทคนิคการโทร MC / DC ซึ่งบางครั้งก็ไม่เข้มงวดพอ

นอกจากนี้เรายังต้องแน่ใจว่าเราได้ครอบคลุมรหัสวัตถุด้วย

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

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

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

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

ซอฟต์แวร์ที่มีความสำคัญอย่างยิ่งในอวกาศจำเป็นต้องมีการรายงานอย่างครอบคลุม 100%

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

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

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

100%

สำหรับ API สาธารณะเช่น java.util Collections นั้นไม่ได้เชื่อมโยงกับฐานข้อมูลและไม่ส่งคืน HTML ฉันคิดว่าการครอบคลุม 100% นั้นเป็นเป้าหมายเริ่มต้นที่สูงส่งแม้ว่าคุณจะชำระ 90-95% เนื่องจากเวลาหรืออื่น ๆ ข้อ จำกัด การครอบคลุมการทดสอบที่เพิ่มขึ้นหลังจากที่คุณมีคุณสมบัติที่สมบูรณ์นั้นทำให้ระดับการตรวจสอบโดยละเอียดมีความละเอียดมากกว่าการทบทวนรหัสประเภทอื่น ๆ หาก API ของคุณเป็นที่นิยมผู้คนก็จะใช้, ซับคลาสนั้น, เลิกทำการซีเรียล ฯลฯ ในวิธีที่คุณคาดไม่ถึง คุณไม่ต้องการประสบการณ์ครั้งแรกในการค้นหาข้อบกพร่องหรือออกแบบการกำกับดูแล!

90%

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

75%

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

50% หรือน้อยกว่า

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

ใกล้ 0%

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

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

0% แน่นอน

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

ฉันซื้อหนังสือเพราะมันอ้างว่าแสดงวิธีจำลองข้อมูลโดยอัตโนมัติสำหรับการทดสอบไฮเบอร์เนต แต่จะทดสอบการสอบถาม Hibernate HQL และ SQL เท่านั้น หากคุณต้องทำ HQL และ SQL จำนวนมากคุณจะไม่ได้รับประโยชน์จากการไฮเบอร์เนต มีรูปแบบของฐานข้อมูลในหน่วยความจำไฮเบอร์เนต แต่ฉันไม่ได้ลงทุนเวลาเพื่อหาวิธีใช้อย่างมีประสิทธิภาพในการทดสอบ หากฉันมีการทำงานแบบนั้นฉันต้องการความครอบคลุมการทดสอบสูง (50% -100%) สำหรับตรรกะทางธุรกิจใด ๆ ที่คำนวณสิ่งต่าง ๆ โดยการนำกราฟวัตถุมาใช้ ความสามารถของฉันในการทดสอบรหัสนี้อยู่ใกล้ 0% ในขณะนี้และเป็นปัญหา ดังนั้นฉันจึงปรับปรุงการครอบคลุมการทดสอบในพื้นที่อื่น ๆ ของโครงการและพยายามที่จะใช้ฟังก์ชั่นที่บริสุทธิ์มากกว่าฟังก์ชั่นที่เข้าถึงฐานข้อมูลส่วนใหญ่เพราะมันง่ายต่อการเขียนการทดสอบสำหรับฟังก์ชั่นเหล่านั้น แต่ถึงกระนั้น

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

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

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

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

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