การเขียนการทดสอบสำหรับรหัสที่ฉันไม่เข้าใจ

ฉันเพิ่งเสร็จสิ้นการปรับโครงสร้างกล่องดำ ฉันไม่สามารถเช็คอินได้เพราะฉันไม่สามารถทดสอบวิธีการได้

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

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

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

มีการโจมตีที่ดีกว่าที่นี่ไหม?

คุณทำได้ดี!

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

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

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

1. ทำความเข้าใจเกี่ยวกับรหัส "จากภายนอก"
2. เขียนการทดสอบการถดถอย
3. refactor ซึ่งนำไปสู่ความเข้าใจที่ดีขึ้นของ internals ของรหัส

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

อย่างไรก็ตามหากมีความเป็นไปได้ที่จะรีเซ็ตสถานะให้หมดจด (หรือสร้างวัตถุทดสอบใหม่ทุกครั้ง) หนึ่งอาจเขียนการทดสอบประเภท "ถังขยะในถังขยะ" ที่เพียงป้อนอินพุตสุ่มไปยังระบบและสังเกตผลลัพธ์

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