ทดสอบโค้ดที่ปรับโครงสร้างใหม่

7 นาที

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

กลยุทธ์การทดสอบระหว่างการปรับโครงสร้างใหม่

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

ใช้ GitHub Copilot สําหรับการสร้างการทดสอบ

ใช้ GitHub Copilot เพื่อสร้างการทดสอบตลอดกระบวนการปรับโครงสร้างใหม่:

ต่อไปนี้คือตัวอย่างบางส่วนของข้อความแจ้งที่คุณสามารถใช้เพื่อสร้างการทดสอบหน่วย:

#codebase /tests Generate unit tests for the ValidateOrderItems method I'm about to extract
Create parameterized tests for CalculateDiscounts with edge cases
Generate test cases for all public methods in the refactored OrderProcessor class

ต่อไปนี้คือตัวอย่างข้อความแจ้งที่คุณสามารถใช้เพื่อสร้างการทดสอบการผสานการทํางาน:

#codebase Generate integration tests for the refactored ProcessOrder method that verify all helper methods are called in the correct sequence
Create integration tests for the OrderProcessor class focusing on the interaction between ValidateOrder, CalculateTotal, and ApplyDiscounts methods
Generate tests that verify error handling flows correctly through the extracted validation methods

แนวทางการทดสอบการถดถอย

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

พิจารณาแนวทางต่อไปนี้:

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

การตรวจสอบประสิทธิภาพ

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

Note

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

แนวทางการทดสอบประสิทธิภาพ

พิจารณาแนวทางต่อไปนี้เมื่อตรวจสอบประสิทธิภาพ:

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

ตัวชี้วัดหลักที่ต้องตรวจสอบ

ติดตามตัวบ่งชี้ประสิทธิภาพเหล่านี้ตลอดการปรับโครงสร้างใหม่:

เวลาดําเนินการสําหรับสถานการณ์ทั่วไป
รูปแบบการจัดสรรหน่วยความจํา
การใช้งาน CPU ภายใต้ภาระ
เปอร์เซ็นไทล์เวลาตอบสนอง (P50, P90, P99)
ปริมาณงานสําหรับการดําเนินการแบบแบตช์

ทดสอบความครอบคลุมระหว่างการปรับโครงสร้างใหม่

รักษาความครอบคลุมที่ครอบคลุมเมื่อคุณแยกและแก้ไขโค้ด:

เป้าหมายความครอบคลุม

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

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

การใช้ GitHub Copilot สําหรับการวิเคราะห์ความครอบคลุม

ขอให้ Copilot ระบุช่องว่างขณะปรับโครงสร้างใหม่:

#codebase What edge cases are not covered in the current test suite?
Suggest test cases for error handling in the methods I'm extracting
Identify untested code paths in the extracted helper functions
List all exception scenarios that should be tested

ข้อผิดพลาดในการทดสอบทั่วไประหว่างการปรับโครงสร้างใหม่

หลีกเลี่ยงข้อผิดพลาดเหล่านี้ขณะทดสอบตลอดกระบวนการปรับโครงสร้างใหม่:

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

รายการตรวจสอบการตรวจสอบคุณภาพ

ใช้รายการตรวจสอบนี้ในระหว่างเซสชันการปรับโครงสร้างใหม่แต่ละครั้งเพื่อให้มั่นใจในคุณภาพ:

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

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

Summary

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

คำติชม

หน้านี้มีประโยชน์หรือไม่