การแข่งขันทดสอบหน่วย

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

เรากำหนดคะแนนสำหรับแต่ละกรณีทดสอบ ดังนั้นถ้าคุณเขียนการทดสอบหน่วยเช่นนี้ ...

for (int i = 0; i < 100; i++) {
  assertTrue(i*i, square(i));
}

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

เราเป็นร้านค้า Java & Javascript เป็นหลัก ดังนั้นฉันจึงแนะนำการนับจำนวนสาขารหัสที่ทดสอบเป็นเมตริก เราสามารถนับจำนวนสาขาที่ทดสอบผ่านเครื่องมือครอบคลุมรหัสได้อย่างง่ายดาย (เช่น EclEmma) อย่างไรก็ตามไม่แน่ใจว่าเราจะทำอย่างไรกับการทดสอบซีลีเนียมของเราและรับรหัสที่ครอบคลุมในแหล่ง Javascript (ความคิดใด ๆ ?)

ไม่มีใครมีข้อเสนอแนะใด ๆ เกี่ยวกับวิธีที่เราสามารถตัดสินผู้ชนะการแข่งขันนี้ได้ดีขึ้น

แก้ไข

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

แก้ไข

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

ไม่มีใครมีข้อเสนอแนะใด ๆ เกี่ยวกับวิธีที่เราสามารถตัดสินผู้ชนะการแข่งขันนี้ได้ดีขึ้น

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

เป็นโบนัสคุณจะได้รับการตรวจสอบจากเพื่อนทุกคน

ดังนั้นถ้าคุณเขียนการทดสอบหน่วยเช่นนี้ ...

for (int i = 0; i < 100; i++) {
 assertTrue(i*i, square(i));
}

คุณจะได้รับ 100 คะแนน

ฉันจะให้คะแนนคนนี้ 0 คะแนน (แม้ว่าการทดสอบกำลังทดสอบสิ่งที่เกี่ยวข้องจริง ๆ ) เนื่องจากการยืนยันภายในลูปทำให้การทดสอบน้อยลงและมีการยืนยันหลายครั้ง (โดยเฉพาะในรูปแบบของลูปหรือแผนที่) นั้นยากที่จะทำงาน

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

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

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

1. โดยใช้ความคิดเห็นคู่สำหรับการทดสอบและมีสิ่งที่คล้ายกับจำนวน WTFs ต่อนาทีตัวชี้วัด

2. วัดจากผลกระทบของการทดสอบเหล่านั้นในช่วงเวลาที่อยู่กับจำนวนของข้อบกพร่อง สิ่งนี้มีประโยชน์หลายประการ:

   • ดูเหมือนว่ายุติธรรม
   • สามารถวัดได้จริงถ้าคุณรวบรวมข้อมูลเพียงพอเกี่ยวกับรายงานบั๊กและชะตากรรมของพวกเขา
   • คุ้มค่าจริงๆ!

3. ใช้ความครอบคลุมสาขาแต่รวมกับตัวชี้วัดอื่น ๆ (รวมถึงบทวิจารณ์) ความครอบคลุมของสาขามีประโยชน์ แต่การทดสอบรหัส CRUD เพียงเพื่อให้ได้เกรดที่ดีกว่าไม่ใช่วิธีที่ดีที่สุดในการใช้เวลาของนักพัฒนา

4. ตัดสินใจทั้งหมดพร้อมกันว่าคุณต้องการบังคับใช้เมตริกใดในขณะนี้ (การตัดสินใจดังกล่าวอาจไม่ได้รับการต้อนรับหรือเป็นไปได้ในบาง บริษัท และทีมงาน) ตรวจสอบและเปลี่ยนการวัดบ่อยครั้งเลือกสิ่งที่เกี่ยวข้องมากขึ้นและให้แน่ใจว่าทุกคนเข้าใจสิ่งที่วัดได้และวิธีการอย่างชัดเจน

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

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

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

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

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