การทดสอบหน่วย Refactor?
เมื่อเราทำงานกับรหัสเดิมและจำเป็นต้องทำการเปลี่ยนแปลงอันดับแรกเราจะเขียนการทดสอบเกี่ยวกับพฤติกรรมปัจจุบัน ด้วยวิธีนี้เราสามารถดำเนินการเปลี่ยนแปลงใหม่ได้อย่างมั่นใจ เรายังสามารถ refactor รหัส
รหัสเดิมมักเป็นรหัสที่ไม่ถูกต้องและหลังจากการปรับโครงสร้างโค้ดใหม่บางส่วนอาจง่ายกว่าและทดสอบได้ง่ายกว่า เนื่องจาก refactor ได้รับการตรวจสอบความถูกต้องโดยการทดสอบแล้วเราควรจะ refactor การทดสอบด้วยถ้าเราสามารถทำให้มันง่ายขึ้น / ชัดเจนขึ้นหรือเก็บไว้ตามที่เขียนไว้?
คำตอบ
การทดสอบอัตโนมัติคือรหัสดังนั้นการรักษารหัสนี้จึงเหมาะสมรวมถึงการปรับโครงสร้างการทดสอบตามความเหมาะสม อย่างไรก็ตาม:
รหัสผลิตภัณฑ์และการทดสอบมีข้อกำหนดด้านคุณภาพที่แตกต่างกัน
- อย่าลงทุนเวลากับสิ่งที่ไม่สำคัญ
รหัสการผลิตควรมีแหล่งเดียวของความจริงในขณะที่การทดสอบควรมีอยู่ในตัวเองเป็นส่วนใหญ่
- การทำสำเนาไม่จำเป็นต้องแย่เสมอไป
และตามที่ Ewan ชี้ให้เห็นคุณไม่ควรเปลี่ยนรหัสและการทดสอบในเวลาเดียวกัน การทดสอบโค้ด + ร่วมกันเป็นระบบทดสอบตัวเอง การเปลี่ยนแปลงในส่วนหนึ่งได้รับการตรวจสอบโดยการรันร่วมกับส่วนอื่น ๆ การเปลี่ยนทั้งสองอย่างในเวลาเดียวกันทำให้เกิดความปลอดภัย สิ่งนี้เป็นไปไม่ได้เสมอไปในทางปฏิบัติ (เช่นเมื่อเปลี่ยนความกังวลข้ามการตัดเฉือนเช่นไลบรารีมาตรฐานพื้นฐาน) แต่คงเป็นเรื่องโง่ที่จะละทิ้งความปลอดภัยนี้โดยไม่ต้องมีความจำเป็นอย่างยิ่ง
เหตุผลทั่วไปที่ฉันปรับโครงสร้างการทดสอบโดยไม่เรียงลำดับเฉพาะ: API ที่กำลังทดสอบมีการเปลี่ยนแปลงเปลี่ยนไปใช้วิธีการทดสอบอื่น (เช่นการทดสอบตามสถานการณ์เทียบกับการทดสอบตามคุณสมบัติการทดสอบระดับ API เทียบกับการทดสอบระดับพฤติกรรม) การเปลี่ยน กรอบการทดสอบ (เช่นเพื่อให้ได้รายงานความล้มเหลวที่ดีขึ้นหรือใช้การทดสอบแบบพารามีทริก) การเปลี่ยนองค์กรทดสอบ (เช่นชุดสไตล์ xUnit และเคสเทียบกับสไตล์ RSpec อธิบาย - มัน) กำจัดการทำซ้ำที่สะสม (เช่นการแยกโค้ดทั่วไปเพื่อสร้างฟิกซ์เจอร์) , …
เมื่อเราทำงานกับรหัสเดิมและจำเป็นต้องทำการเปลี่ยนแปลงอันดับแรกเราจะเขียนการทดสอบเกี่ยวกับพฤติกรรมปัจจุบัน ด้วยวิธีนี้เราสามารถดำเนินการเปลี่ยนแปลงใหม่ได้อย่างมั่นใจ เรายังสามารถ refactor รหัส
นั่นอาจสะท้อนถึงกระบวนการทำงานของคุณในบางครั้ง แต่จากประสบการณ์ของฉันวิธีที่มีประสิทธิภาพมากกว่าคือ:
คุณเขียนแบบทดสอบ
คุณ refactor เพื่อทำการเปลี่ยนแปลงได้ง่ายขึ้น
คุณดำเนินการเปลี่ยนแปลง
ด้วยวิธีนี้จะเห็นได้ชัดมากขึ้นว่าคุณ refactor เมื่อมีเหตุผลที่แท้จริงสำหรับการเปลี่ยนแปลงไม่ใช่เพียงเพราะรหัส "ไม่สะอาดอีกต่อไป"
ตอนนี้พยายามที่จะใช้มาตรการเดียวกันกับการทดสอบของคุณ: คุณไม่ refactor ทดสอบของคุณเพราะ"พวกเขาไม่ได้ทำความสะอาดใด ๆ เพิ่มเติม" คุณปรับโครงสร้างใหม่เมื่อพวกเขาเริ่มขัดขวางคุณในการเปลี่ยนแปลงรหัสที่มีอยู่ของคุณได้อย่างง่ายดาย
ตัวอย่างเช่นเมื่อคุณมีการทดสอบสิบรายการทั้งหมดที่เรียกใช้วิธีการสาธารณะเดียวกันของคลาสภายใต้การทดสอบในขณะที่ในรหัสการผลิตของคุณมีการเรียกวิธีการสาธารณะในที่เดียวเท่านั้นนี่คือรูปแบบของการทำซ้ำรหัสโดยการทดสอบซึ่งอาจขัดขวางคุณ เปลี่ยนลายเซ็นของวิธีการสาธารณะนั้น
ฉันมักจะปล่อยให้มันเป็นอย่างนั้นจนกว่าคุณจริงๆได้รับความต้องการสำหรับหลังหรือทั่วไปมากขึ้นเมื่อคุณสังเกตเห็นการทำสำเนารหัสนี้คุณจะต้องทำการเปลี่ยนแปลงเดียวกันในการทดสอบของคุณในหลายสถานที่
คุณอาจต้องการเริ่มต้นด้วยการปรับโครงสร้างการทดสอบใหม่
การทดสอบจะจับสิ่งที่แอปพลิเคชันเดิมทำ เอกสารประเภทหนึ่ง การทดสอบจะบอกคุณว่าอินพุตและเอาต์พุตโค้ดบอกให้คุณประมวลผล หากการทดสอบไม่ดีการจัดเตรียม (ขึ้นอยู่กับว่าการทดสอบนั้นแย่เพียงใด) จะช่วยให้คุณเข้าใจโค้ด
นอกจากนี้ยังเป็นวิธีที่ดีในการตัดสินว่าการทดสอบเพิ่มคุณค่าหรือไม่ ระบบเดิมที่ฉันใช้มีความครอบคลุมของรหัสที่ดี แต่ในการตรวจสอบการทดสอบที่ยืนยันในสิ่งที่ไม่มีจุดหมาย ... เช่นการตรวจสอบว่า Getters และ Setters ทำงานได้ (การทดสอบกรอบงาน. NET ไม่ใช่แอปพลิเคชัน)
เมื่อคุณได้รับการทดสอบทั้งหมดแล้วคุณจะมีความเข้าใจโค้ดมากขึ้นจากนั้นคุณจะสามารถตัดสินใจได้ดีขึ้นเกี่ยวกับวิธีการปรับโครงสร้างโค้ดใหม่