เป็นความคิดที่ดีหรือไม่ที่จะวัดประสิทธิภาพของวิธีการโดยใช้การทดสอบหน่วยหมดเวลา?
ในโครงการที่มีข้อกำหนดที่ไม่สามารถใช้งานได้ซึ่งระบุเวลาดำเนินการสูงสุดสำหรับการดำเนินการที่เฉพาะเจาะจง QA จะต้องตรวจสอบประสิทธิภาพของการกระทำนี้บนเครื่องเฉพาะโดยใช้ฮาร์ดแวร์ที่แม่นยำภายใต้ภาระที่แม่นยำทั้งฮาร์ดแวร์และโหลดที่ระบุไว้ในข้อกำหนด ในทางกลับกันการเปลี่ยนแปลงซอร์สโค้ดที่ผิดพลาดบางอย่างอาจส่งผลกระทบอย่างรุนแรงต่อประสิทธิภาพ สังเกตเห็นผลกระทบเชิงลบนี้ในช่วงต้น , ก่อนรหัสที่มาถึงการควบคุมแหล่งที่มาและได้รับการยืนยันโดยแผนก QA, อาจจะเป็นประโยชน์ในแง่ของเวลาที่หายไปโดยแผนก QA รายงานปัญหาและโดยนักพัฒนาแก้ไขมันหลายกระทำในภายหลัง หากต้องการทำสิ่งนี้เป็นความคิดที่ดี: ในการใช้การทดสอบหน่วยเพื่อให้ทราบถึงเวลาที่ใช้ในการดำเนินการแอ็คชั่นเดียวกัน² nครั้ง หากต้องการใช้การหมดเวลาทดสอบต่อหนึ่งครั้งผ่าน[TestMethod, Timeout(200)]แอตทริบิวต์ใน C # ฉันคาดว่าจะมีปัญหาหลายอย่างเกี่ยวกับวิธีการนี้: ตามหลักการแล้วการทดสอบหน่วยไม่ได้สำหรับสิ่งนั้นจริง ๆ พวกเขาคาดหวังว่าจะทดสอบโค้ดเพียงส่วนเล็ก ๆ ไม่มีอะไรเพิ่มเติม: ทั้งการตรวจสอบข้อกำหนดการใช้งานหรือการทดสอบการรวมเข้าด้วยกันหรือการทดสอบประสิทธิภาพ การทดสอบหน่วยหมดเวลาใน Visual Studio วัดจริง ๆ ว่าจะวัดได้หรือไม่โดยคำนึงถึงว่าการเตรียมใช้งานและการล้างข้อมูลนั้นไม่มีอยู่สำหรับการทดสอบเหล่านั้นหรือสั้นเกินไปที่จะส่งผลกระทบต่อผลลัพธ์หรือไม่ การวัดประสิทธิภาพด้วยวิธีนี้น่าเกลียด การใช้เบนช์มาร์กบนเครื่องใด ๆ โดยไม่ขึ้นกับฮาร์ดแวร์โหลด ฯลฯ ก็เหมือนกับการทำเบนช์มาร์กที่แสดงว่าผลิตภัณฑ์ฐานข้อมูลหนึ่งจะเร็วกว่าผลิตภัณฑ์อื่นเสมอ บนมืออื่น ๆ ที่ผมไม่ได้คาดหวังว่าผู้ทดสอบหน่วยที่จะเป็นผลที่ชัดเจนหรือสิ่งที่ถูกใช้โดยแผนก QA การทดสอบหน่วยเหล่านั้นจะถูกนำมาใช้เพียงเพื่อให้ความคิดทั่วไปเกี่ยวกับประสิทธิภาพที่คาดหวังและเป็นหลักในการแจ้งเตือนนักพัฒนาว่าการปรับเปลี่ยนครั้งสุดท้ายของเขายากจนบางสิ่งบางอย่างอย่างรุนแรงส่งผลกระทบต่อประสิทธิภาพการทำงาน การทดสอบการพัฒนาแบบขับเคลื่อน (TDD)เป็นไปไม่ได้สำหรับการทดสอบ ในตอนแรกมันจะล้มเหลวอย่างไรก่อนที่จะเริ่มใช้โค้ด การทดสอบประสิทธิภาพมากเกินไปจะส่งผลต่อเวลาที่ต้องใช้ในการทดสอบดังนั้นวิธีนี้ จำกัด เฉพาะการกระทำสั้น ๆ เท่านั้น …