เราควรแยกรหัสสำหรับการวิเคราะห์ความครอบคลุมรหัสหรือไม่


15

ฉันทำงานกับแอพพลิเคชั่นหลายตัว ปัจจุบันการครอบคลุมโค้ดของพวกเขาค่อนข้างต่ำ: โดยทั่วไประหว่าง 10 และ 50%

ตั้งแต่หลายสัปดาห์เราได้พูดคุยกับทีมงานบังกาลอร์ (ส่วนหลักของการพัฒนาในต่างประเทศในอินเดีย) เกี่ยวกับการยกเว้นแพคเกจหรือคลาสสำหรับ Cobertura (เครื่องมือครอบคลุมรหัสของเราแม้ว่าเราจะย้ายไปที่ JaCoCo)

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

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

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

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

นอกจากนี้เราจะไม่สามารถทราบได้อย่างชัดเจนถึงสิ่งที่ถูกพิจารณาในการวัดความครอบคลุมโค้ด ตัวอย่างเช่นถ้าฉันมี 10,000 เส้นของการประยุกต์ใช้รหัสที่มี 40% ของความคุ้มครองรหัสผมสามารถหักค่าใช้จ่ายที่ 40% ของฐานรหัสของฉันมีการทดสอบ(2) แต่จะเกิดอะไรขึ้นถ้าเราตั้งค่าการยกเว้น หากรหัสครอบคลุมอยู่ในขณะนี้ 60% ฉันจะหักอะไรได้แน่ มีการทดสอบ 60% ของรหัสฐาน "สำคัญ" ของฉันหรือไม่ ฉันสามารถ

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

ความคิดเห็นของคุณเกี่ยวกับเรื่องนี้คืออะไร? คุณทำโครงการของคุณอย่างไร

ขอบคุณ

(1)เลเยอร์เหล่านี้มักเกี่ยวข้องกับ UI / Java beans เป็นต้น

(2)ฉันรู้ว่าไม่เป็นความจริง ในความเป็นจริงมันหมายความว่า 40% ของฐานรหัสของฉันเท่านั้น


พวกเขาทำสัญญากับความคุ้มครองที่เฉพาะเจาะจงหรือไม่?
jk

คำตอบ:


3

โดยทั่วไปฉันไม่รวมรหัสที่สร้างขึ้นอัตโนมัติเช่นไคลเอนต์ WCF ที่ Visual Studio สร้าง มักจะมีบรรทัดของโค้ดจำนวนมากและเราจะไม่ทดสอบพวกเขา สิ่งนี้ทำให้ขวัญเสียมากในการเพิ่มการทดสอบกับโค้ดขนาดใหญ่ที่อื่นและเพิ่มความครอบคลุมโค้ดเพียง 0.1%

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

แต่ในฐานะที่เป็นจุดเปลี่ยนฉันจะยกเว้นการทดสอบหน่วยด้วยตนเอง พวกเขาควรได้รับความคุ้มครองประมาณ ~ 100% และพวกเขาคิดเป็นเปอร์เซ็นต์ของโค้ดฐานที่มาก


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

ฉันหมายถึงการจัดการข้อผิดพลาดสำหรับการทดสอบหน่วยเองเช่น ... การทดสอบกำลังทำงานอยู่ แต่ดิสก์เต็มดังนั้นการทดสอบหน่วยโดยใช้ IO จะล้มเหลวในการคาดหวัง
94239

อืมม ไม่ฉันผิด การทดสอบเหล่านั้นไม่ได้ดำเนินการอย่างถูกต้อง จะลบความคิดเห็นทั้งหมดเหล่านี้ในภายหลัง
94239

3

คำถามที่ดี. โดยทั่วไปแล้วฉันมักจะแยกรหัสออกจากการครอบคลุมรหัสด้วยเหตุผลบางอย่างเช่น:

  • สร้าง
  • มรดก (ไม่อัปเดตอีกต่อไป)
  • มันมาที่นี่: บางชั้นฉันไม่ต้องการทดสอบ

ทำไมประเด็นสุดท้าย ฉันคิดว่ามันเป็นวิธีปฏิบัติที่ดีที่จะมุ่งเน้นสิ่งที่ฉันสนใจขณะที่หยุดการรบกวน หากคุณไม่ต้องการทดสอบ UI-Layer ทำไมต้องคำนึงถึง - มันจะดึงดูดความสนใจจากส่วนสำคัญของซอฟต์แวร์ของคุณ - ตรรกะทางธุรกิจเท่านั้น

แต่:

  1. คุณควรมีเหตุผลที่ดีทำไมต้องยกเว้นเลเยอร์บางอย่างจากการทดสอบหน่วยเลย (อาจมีคำถาม - จากหัวหน้าของคุณเพื่อนร่วมทีมสื่อกด ;-)
  2. หากคุณต้องการให้พวกเขาทดสอบเลเยอร์เหล่านี้คุณควรรวมพวกเขาไว้ในสถิติเพื่อแสดงทีมทั้งหมดทุกวันว่าเป็นสิ่งสำคัญและจำเป็นต้องทำ

สุดท้าย: อย่านำตัวเลขที่ร้ายแรงเกินไป ความครอบคลุม 30% อาจพิสูจน์ได้ว่าเป็นซอฟต์แวร์ที่มั่นคงเมื่อมันเป็นส่วนสำคัญของซอฟต์แวร์


1

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

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


1

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

ด้วยความรู้ที่ จำกัด ของฉันฉันมีสิ่งนี้จะพูดว่า:

  1. อย่าปล่อยให้ตัวเลขจากเครื่องมือทดสอบใด ๆ ขัดขวางการทดสอบของคุณ
  2. หากคลาสมีความซับซ้อนและไม่สามารถทำการทดสอบหน่วยได้เป็นความคิดที่ดีที่จะคำนึงถึงคลาสนั้นอีกครั้งในคลาสที่กะทัดรัดและทดสอบได้มากขึ้น มันจะต้องใช้ความพยายามและความทุ่มเทมากมาย แต่จะจ่ายในระยะยาว
  3. การทดสอบองค์ประกอบ UI อาจยาก แต่คุณยังคงสามารถทดสอบฟังก์ชั่นที่กำลังดำเนินการโดยส่วนประกอบเหล่านั้น
  4. หากคุณกำลังทำโครงการบนเว็บคุณสามารถใช้ QUnit เพื่อทดสอบหน่วยฝั่งไคลเอ็นต์ทั้งหมด

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


1
ขอบคุณสำหรับคำตอบของคุณ แต่คำถามนั้นเกี่ยวข้องกับการวิเคราะห์ความครอบคลุมและการยกเว้นไม่มากเกี่ยวกับวิธีการทดสอบเลเยอร์ที่นักพัฒนา "ไม่ต้องการทดสอบ" ไม่ว่าจะตีความหมายเลขนี้อย่างไร (แม้ว่าฉันจะเห็นด้วย กับคุณในความจริงที่ว่านี่เป็นเพียงตัวเลข)
Romain Linsolas

0

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


0

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

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

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

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