การทดสอบหน่วยรหัสขั้นตอนมีประสิทธิภาพ?

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

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

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

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

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

โปรดทราบว่าคุณจะต้อง:

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

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

• จัดการกับรหัสฟังก์ชั่นนอก นี่เป็นกรณีที่ซับซ้อนมากขึ้น แต่ก็ยังเป็นไปได้ ไม่ว่าคุณจะrequire_onceเป็นหน้าเว็บเพื่อดูว่าเกิดอะไรขึ้นและจับเอาท์พุทผ่านob_start/ob_get_cleanหรือคุณทำคำขอ HTTP จากชุดทดสอบและวิเคราะห์การตอบสนองโดยการแยกวิเคราะห์ HTML นี่ไม่ใช่การทดสอบ UI จริง ๆ : ที่นี่คุณไม่สนใจว่าปุ่มบนหน้าเว็บจะปรากฏที่ด้านซ้ายหรือด้านขวาหรือถ้าลิงก์อยู่ในตัวพิมพ์ใหญ่สีแดงหรือสีน้ำเงินเล็ก ๆ สิ่งที่คุณสนใจคือการค้นหาองค์ประกอบ HTML ผ่าน DOMและเปรียบเทียบเนื้อหากับองค์ประกอบที่คาดหวัง

• ทดสอบรหัสการตอบสนอง require_onceการบัฟเฟอร์เอาต์พุตนั้นดี แต่คุณต้องทดสอบว่าเว็บแอ็พพลิเคชันจัดการกับข้อผิดพลาดอย่างไร ตัวอย่างเช่นหากผลลัพธ์ที่คาดหวังจากการทดสอบคือ 404 ไม่พบคุณต้องทำคำขอ HTTP เพื่อที่จะทราบว่าการตอบสนองคืออะไร

แนะนำให้เลื่อนออกไปจนกว่าแอปพลิเคชั่นจะถูกย้ายไปยังกรอบงาน OOP ที่เหมาะสม

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

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

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

• ใช้ของกลม
• ผลข้างเคียง
• รหัสคู่แน่น
• รหัสคู่ที่ไม่ดี
• เงื่อนไขจำนวนมาก
• ออกแบบ "หน่วย" ไม่ดี

สิ่งเหล่านี้จะส่งผลกระทบต่อความยากลำบากในการทดสอบสูงกว่ากระบวนทัศน์ทางภาษา

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

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

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

ที่กล่าวว่าหากคุณสามารถทดสอบการนั่งร้านรอบ ๆ วิธีการที่ทำให้เกิดความเจ็บปวดมากที่สุด