เครื่องมือ / คำแนะนำเกี่ยวกับวิธีการปฏิเสธอาร์กิวเมนต์คุณภาพของรหัสครอบคลุม

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

เมื่อเร็ว ๆ นี้ฉันไม่เห็นด้วยกับบางคนเกี่ยวกับการครอบคลุมโค้ด ฉันมีกลุ่มคนที่ต้องการให้ทีมงานของเราลดการมองการครอบคลุมโค้ดทั้งหมดโดยอ้างว่าการครอบคลุม 100% ไม่ได้หมายถึงการทดสอบคุณภาพที่ดีและรหัสคุณภาพดี

ฉันสามารถผลักดันกลับได้โดยการขายอาร์กิวเมนต์ที่ Code Coverage บอกฉันว่ายังไม่ได้ทดสอบอย่างแน่นอนและช่วยให้เรามุ่งเน้นไปที่พื้นที่เหล่านั้น

(ข้างต้นได้รับการกล่าวถึงในลักษณะคล้ายกันในคำถาม SO อื่น ๆ เช่นนี้ - /programming/695811/pitfalls-of-code-coverage )

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

ในขณะที่ผมเข้าใจมุมมองของผมกำลังมองหาวิธีที่จะทำให้เป็นกรณีที่แข็งแกร่งมากขึ้นสำหรับความคุ้มครองรหัสโดยการแนะนำเครื่องมือที่มีประสิทธิภาพมากขึ้น / (Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc)กรอบที่ดูแลเกณฑ์ที่ครอบคลุมมากขึ้น

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

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

แก้ไข: เพื่อลดความสับสนเกี่ยวกับการเข้าใจจุดอ่อนของการครอบคลุมโค้ดทั่วไปฉันต้องการชี้ให้เห็นว่าฉันไม่ได้อ้างถึงเครื่องมือ Statement Coverage (หรือบรรทัดของการเรียกใช้โค้ด) (มีจำนวนมาก) ในความเป็นจริงที่นี่เป็นบทความที่ดีเกี่ยวกับทุกสิ่งที่ผิดกับมัน: http://www.bullseye.com/statementCoverage.html

ฉันกำลังมองหามากกว่าแค่คำแถลงหรือคำแถลงเรื่องของสายซึ่งจะครอบคลุมเกณฑ์และระดับความครอบคลุมที่หลากหลาย

ดู: http://en.wikipedia.org/wiki/Code_coverage#Coverage_criteria

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

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

แก้ไข: จนถึงสิ่งที่ฉันมีจากคำตอบ:

• การตรวจสอบรหัสควรครอบคลุมการทดสอบเพื่อให้มั่นใจในคุณภาพการทดสอบ
• ทดสอบกลยุทธ์แรกช่วยหลีกเลี่ยงการทดสอบที่เขียนขึ้นหลังจากข้อเท็จจริงเพื่อเพิ่มความครอบคลุม%
• การสำรวจเครื่องมือทางเลือกอื่น ๆ ที่ครอบคลุมถึงเกณฑ์การทดสอบอื่น ๆ นอกเหนือจากเพียง Statement / Line
• การวิเคราะห์รหัสที่ครอบคลุม / จำนวนข้อบกพร่องที่พบจะช่วยชื่นชมความสำคัญของการครอบคลุมและทำให้เป็นกรณีที่ดีกว่า
• สิ่งสำคัญที่สุดคือความเชื่อมั่นของทีมที่จะทำสิ่งที่ถูกต้องและต่อสู้เพื่อความเชื่อของพวกเขา
• บล็อกที่ครอบคลุม / # ของการทดสอบ - เป็นที่ถกเถียงกันอยู่ แต่ถือค่าบางอย่าง

ขอบคุณสำหรับคำตอบที่ยอดเยี่ยม ฉันซาบซึ้งจริงๆ หัวข้อนี้ดีกว่าการระดมสมองชั่วโมงด้วยพลังที่เป็น

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

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

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

ออกก่อนคนทำสนับสนุนความคุ้มครอง 100%:

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

Steve McConnell, Code Complete , บทที่ 22: การทดสอบนักพัฒนา

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

ฉันขอแนะนำให้แก้ไขข้อโต้แย้งด้วยการรวบรวมและวิเคราะห์ข้อมูลในโครงการของคุณเอง

ในการรวบรวมข้อมูลฉันใช้เครื่องมือต่อไปนี้เป็นการส่วนตัว:

• JaCoCoและปลั๊กอินEclEmma ที่เกี่ยวข้องสำหรับการวัดความครอบคลุมโค้ด
• สคริปต์Antสำหรับการสร้างการทดสอบและการรายงานอัตโนมัติ
• Jenkinsสำหรับงานสร้างต่อเนื่อง - การเปลี่ยนแปลงใด ๆ ในการควบคุมแหล่งทริกเกอร์การสร้างอัตโนมัติ
• ปลั๊กอิน JaCoCoสำหรับเจนกินส์ - รวบรวมเมตริกการครอบคลุมสำหรับแต่ละบิลด์และแนวโน้มกราฟ ยังอนุญาตนิยามของขอบเขตการครอบคลุมต่อโปรเจ็กต์ที่มีผลต่อความสมบูรณ์ของบิลด์
• Bugzillaสำหรับติดตามบั๊ก

เมื่อคุณมีสิ่งนั้น (หรืออะไรทำนองนี้) เข้าที่คุณสามารถเริ่มดูข้อมูลของคุณเองอย่างใกล้ชิดยิ่งขึ้น:

• พบข้อบกพร่องมากขึ้นในโครงการที่ครอบคลุมไม่ดี?
• พบข้อบกพร่องมากขึ้นในชั้นเรียน / วิธีการที่ครอบคลุมไม่ดี?
• เป็นต้น

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

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

นี้เป็นปัญหาของความไว้วางใจไม่ได้เครื่องมือ

ถามพวกเขาว่าทำไมถ้าพวกเขาเชื่อคำสั่งนั้นจริง ๆ พวกเขาจะไว้ใจทีมให้เขียนโค้ดใด ๆ เลย?

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

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

ซึ่งเป็นสิ่งที่สมเหตุสมผลเว้นแต่คุณจะพิสูจน์ว่ากระบวนการและมาตรการระดับโลกนั้นมีคุณค่าและเป็นผลดีต่อคุณภาพและความเร็วในการพัฒนา

เส้นเวลาปกติ:

1. dev: เฮ้ดู - ฉันเพิ่มการวัดความครอบคลุมโค้ดลงในแดชบอร์ดของเราไม่ดีขนาดนั้นหรือ
2. ผู้จัดการ: แน่นอนเรามาเพิ่มเป้าหมายที่จำเป็น
3. dev: ไม่เป็นไรการครอบคลุมโค้ดนั้นโง่และไร้ประโยชน์ลองปล่อยมัน

จากประสบการณ์ของฉันมีบางสิ่งที่จะรวมเข้ากับการครอบคลุมโค้ดเพื่อให้การวัดคุ้มค่า:

รีวิวรหัส

หากคุณสามารถถ่อการทดสอบที่ไม่ดีกลับไปที่ผู้พัฒนามันสามารถช่วย จำกัด จำนวนการทดสอบที่ไม่ดีที่ให้ความคุ้มครองที่ไม่มีความหมายนี้

การติดตามบั๊ก

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

ปฏิบัตินิยม

ไม่มีใครจะไปถึง 100% ด้วยการทดสอบที่ดีเกี่ยวกับรหัสที่ไม่สำคัญ หากคุณในฐานะผู้นำทีมดูที่การครอบคลุมรหัส แต่แทนที่จะพูดว่า "เราต้องไปให้ถึง N%!" คุณระบุช่องว่างและขอให้ผู้คน "ปรับปรุงการครอบคลุมในโมดูล X" ที่บรรลุเป้าหมายของคุณโดยไม่ต้องให้โอกาสผู้อื่นเล่นเกมระบบ

บล็อกที่ครอบคลุม / # ของการทดสอบ

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

นี่คือ 2 เซ็นต์ของฉัน

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

ตัวอย่างบางส่วน:

• เขียนการทดสอบหน่วยที่มีรหัสครอบคลุม 100% และคุณจะได้รหัสที่มีคุณภาพดีขึ้น
• ใช้ TDD อย่างเป็นระบบและคุณจะได้รับการออกแบบที่ดีขึ้น
• ทำการจับคู่การเขียนโปรแกรมและคุณจะปรับปรุงคุณภาพรหัสและลดเวลาในการพัฒนา

ฉันคิดว่าปัญหาพื้นฐานของข้อความข้างต้นคือมนุษย์ไม่ใช่คอมพิวเตอร์และซอฟต์แวร์การเขียนไม่เหมือนกับการใช้อัลกอริทึม

ดังนั้นข้อความข้างต้นมีความจริงบางอย่าง แต่ทำให้สิ่งต่าง ๆ ง่ายขึ้นเล็กน้อยเช่น:

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

กลับไปที่การครอบคลุมโค้ด

ฉันสามารถผลักดันกลับได้โดยการขายอาร์กิวเมนต์ที่ Code Coverage บอกฉันว่ายังไม่ได้ทดสอบอย่างแน่นอนและช่วยให้เรามุ่งเน้นไปที่พื้นที่เหล่านั้น

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

โมดูลดำเนินการคำนวณที่สำคัญและซับซ้อนหรือไม่ จากนั้นฉันต้องการทดสอบโค้ดทุกบรรทัด แต่ยังเขียนการทดสอบหน่วยที่มีความหมาย (การทดสอบหน่วยที่เข้าใจได้ง่ายในโดเมนนั้น)

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

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

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

หากคุณกดรหัส 100% ลงบนนักพัฒนาบางคนจะเริ่มเขียนการทดสอบหน่วยโง่เพื่อปฏิบัติตามภาระหน้าที่ของพวกเขาแทนการพยายามเขียนการทดสอบที่สมเหตุสมผล

คุณจัดสรรเวลารับประกันอย่างไรโดยไม่ต้องมีมาตรการใด ๆ

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

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

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

นี่เป็นความเสี่ยงที่แท้จริงไม่ใช่แค่ทางทฤษฎี

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

"คำแนะนำสำหรับการรวมกันของเครื่องมือการครอบคลุมโค้ดและการปฏิบัติ / กระบวนการที่จะไปกับพวกเขา"

นอกจากคำแนะนำอื่น ๆ ทั้งหมดแล้วยังมีเทคนิคการทำงานอัตโนมัติหนึ่งอย่างที่สามารถประเมินคุณภาพของการทดสอบคือการทดสอบการกลายพันธุ์ ( http://en.wikipedia.org/wiki/Mutation_testing ) สำหรับโค้ด Java, PIT ( http://pitest.org/ ) ทำงานได้และเป็นเครื่องมือทดสอบการกลายพันธุ์ครั้งแรกที่ฉันได้พบ

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

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

แต่ถ้าหากพวกเขาไม่สามารถพิสูจน์ได้ว่าการทดสอบหน่วยทั้งหมดนั้นดี (สำหรับคำจำกัดความของความดีใด ๆ ที่พวกเขาสามารถเกิดขึ้นได้) นี่เป็นจุดที่เงียบเชียบ

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

"เราใกล้จะทำยังไงดี?"

"คุณภาพของระบบนี้เป็นอย่างไร"

"โมดูลเหล่านี้มีความซับซ้อนเพียงใด"

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

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

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

เมตริกฉันได้พบว่ามีประโยชน์ในการทำประมาณที่ดีคือCrap4J ตอนนี้หมดอายุแล้ว แต่คุณสามารถย้ายพอร์ต / ติดตั้งด้วยตนเองได้อย่างง่ายดาย Crap4J พยายามเชื่อมโยงความครอบคลุมของรหัสกับความซับซ้อนของวงจรโดยอ้างว่ารหัสที่ซับซ้อนกว่า (ifs, whiles, fors เป็นต้น) ควรมีการทดสอบที่ครอบคลุมมากขึ้น สำหรับฉันแล้วความคิดแบบเรียบง่ายดังจริง ๆ ฉันต้องการที่จะเข้าใจว่าฐานความเสี่ยงของฉันอยู่ที่ไหนและความเสี่ยงที่สำคัญอย่างหนึ่งคือความซับซ้อน ดังนั้นการใช้เครื่องมือนี้ฉันสามารถประเมินความเสี่ยงของรหัสฐานของฉันได้อย่างรวดเร็ว ถ้ามันซับซ้อนการรายงานข่าวก็จะดีขึ้น ถ้าไม่ฉันไม่ต้องเสียเวลาพยายามที่จะได้รับรหัสทุกบรรทัดที่ครอบคลุม

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

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

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

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