ควรทำการตรวจสอบโค้ดก่อนหรือหลังการทดสอบหน่วย

ฉันกำลังถกเถียงกับเพื่อนร่วมงานของฉันในเวลาที่จะทำการตรวจสอบโค้ด - ก่อนหรือหลังการทดสอบหน่วย การปฏิบัติที่ดีที่สุดคืออะไร?

ปัจจัยบางประการที่เราอาจต้องคำนึงถึง (อาจมีมากกว่านี้):

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

คุณควรทดสอบหน่วยก่อนทำการตรวจสอบโค้ดและนี่คือสาเหตุ

1. หากรหัสของคุณเสียในลักษณะที่จะถูกจับได้โดยการทดสอบหน่วยคุณจะเสียเวลาของนักพัฒนาคนอื่น ๆ โดยให้พวกเขามีส่วนร่วมในวงจรสีแดง / เขียว / refactor
2. การทดสอบแสดงให้นักพัฒนารายอื่นทราบถึงการใช้งานโค้ดซึ่งทำให้ง่ายต่อการตรวจสอบ
3. ควรตรวจสอบการทดสอบพร้อมกับรหัสที่ทดสอบในกรณีที่คุณไม่มีกรณีทดสอบหรือการทดสอบของคุณไม่ทำงานอย่างถูกต้อง
4. การทดสอบและการตรวจสอบโค้ดมักจะพบปัญหาที่แตกต่างกันโดยมีการเหลื่อมกันเล็กน้อยในปัญหาที่พบ การทดสอบหน่วยจะไม่ได้รับความรำคาญเมื่อต้องทดสอบรหัสอีกครั้งเมื่อผู้ตรวจสอบพบปัญหานักพัฒนาจะรำคาญและอาจจะไม่ทำเช่นนั้นเป็นครั้งที่สองผ่าน

อาจมีเหตุผลอื่น ๆ แต่สิ่งเหล่านั้นเป็นสิ่งที่ฉันเคยเห็นและมีประสบการณ์มาก่อนในการใช้การตรวจสอบโค้ดภายใน 3 ทีม / บริษัท

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

รีวิวรหัสมีไว้สำหรับเมื่อรหัสเป็น "เสร็จสิ้น"

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

นอกจากนี้การทดสอบจำเป็นต้องตรวจสอบและปรับโครงสร้างใหม่เพื่อให้เข้าใจได้ว่ามันเป็นส่วนหนึ่งของการทบทวนรหัส

การทดสอบควรได้รับการพิจารณาเป็นส่วนหนึ่งของรหัสเพื่อทบทวน ดังนั้นจึงเหมาะสมที่จะทบทวนหลังจากทำแบบทดสอบเสร็จแล้ว

ตรวจสอบให้แน่ใจว่ามีการตรวจสอบเช่นกัน นี่เป็นสิ่งสำคัญสำหรับผู้ที่ยังใหม่กับการทดสอบหน่วย

ตรวจสอบให้แน่ใจว่าทีมของคุณได้รับการสนับสนุนการพึ่งพากรอบการแยกการจำลอง mocks vs stubs ตะเข็บการทดสอบที่ทำปฏิกิริยากับสถานะและการทดสอบการรวมเข้าด้วยกัน

คุณไม่จำเป็นต้องใช้หัวข้อดังกล่าว แต่คุณควรเข้าใจ

ดี,

ขึ้นอยู่กับสิ่งที่คุณหมายถึงโดย "การทดสอบหน่วย" ...

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

และ

ถ้าเป็นคลาสสิก "การทดสอบหน่วย" [อะไรก็ตามที่มันหมายถึงฉันไม่รู้ แต่ฉันหมายถึงการทดสอบหลังจากที่คุณเขียนรหัสและทำโดยคนอื่นทั่วไป] แล้วเกณฑ์หลักคือสิ่งที่คุณคาดหวังจาก codereview และลักษณะของการทดสอบหน่วย: ถ้า คุณต้องการคำติชมอย่างรวดเร็วทำการตรวจสอบและดำเนินการและไม่มีการทดสอบหน่วยอัตโนมัติคุณจะต้องรอการทดสอบหน่วย หากคุณต้องการระบุปัญหาผู้ใหญ่ด้วยการตรวจสอบโค้ดและใช้วิธีแก้ปัญหาแบบเพิ่มหน่วยสำหรับการทำซ้ำครั้งถัดไปคุณสามารถทำได้ก่อนทดสอบหน่วย ...

แต่หลังจากทั้งหมดส่วนตัวสำหรับ codereview หลังจากหรือหลังทดสอบหน่วยไม่ได้เป็นเกณฑ์จริงสำหรับฉัน ...

ทำไมเราถึงทำ codereview สำหรับคุณภาพของรหัส ... แทนที่จะเป็นประตู "การควบคุมคุณภาพ" ฉีดคุณภาพลงในกระบวนการพัฒนาซอฟแวร์ของคุณ - สิ่งแวดล้อม ...

ฉันมักจะพูดกันว่า "ว่องไว" ... อย่ารอให้โค้ดเสร็จสิ้นเพื่อทำการตรวจสอบโค้ดอย่างไม่เป็นทางการ: มีนักพัฒนาซอฟต์แวร์ที่คุณสามารถรอได้ทั้งหมด code + test phasis จะแล้วเสร็จ ... แต่

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

หากนักพัฒนาซอฟต์แวร์ใหม่ให้กับทีมได้เป็นอย่างดีรหัสการตรวจสอบในช่วงต้นและอาจจะบ่อย

และโดยวิธีการทดสอบหน่วยก็จำเป็นต้องมีการตรวจสอบรหัส