การพัฒนาที่ขับเคลื่อนด้วยการทดสอบบังคับให้ฉันต้องติดตาม SOLID หรือไม่

ฉันได้ยินมามากมายจากผู้ฝึกอบรมTDDว่าข้อดีอย่างหนึ่งของ TDD คือบังคับให้นักพัฒนาปฏิบัติตามหลักการของSOLID (ความรับผิดชอบเดี่ยว, เปิด - ปิด, การทดแทน Liskov, การแยกอินเตอร์เฟสและการผกผันการพึ่งพา) แต่สำหรับฉันแล้วมันก็เพียงพอแล้วที่จะเขียนการทดสอบ (การทดสอบหน่วยเบื้องต้น) เพื่อให้เข้าใจว่าการติดตาม SOLID เป็นสิ่งสำคัญ

TDD บังคับให้ผู้พัฒนาติดตาม SOLID มากกว่าการเขียนบททดสอบหรือไม่?

ประการแรก TDD ไม่ได้บังคับให้คุณเขียนรหัส SOLID อย่างเคร่งครัด คุณสามารถทำ TDD และสร้างระเบียบหนึ่งถ้าคุณต้องการ

แน่นอนว่าการรู้หลักการ SOLID ช่วยได้เพราะไม่เช่นนั้นคุณอาจท้ายไม่ได้รับคำตอบที่ดีสำหรับปัญหามากมายของคุณและด้วยเหตุนี้จึงเขียนโค้ดที่ไม่ดีพร้อมกับการทดสอบที่ไม่ดี

หากคุณรู้เกี่ยวกับหลักการของ SOLID อยู่แล้ว TDD จะสนับสนุนให้คุณคิดถึงพวกเขาและใช้มันอย่างแข็งขัน

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

ตัวอย่างเช่น:

1. คุณต้องเขียนโค้ดแยกเพื่อให้คุณสามารถเยาะเย้ยสิ่งที่คุณต้องการ นี้สนับสนุนการพึ่งพาผกผันหลักการ
2. คุณต้องเขียนการทดสอบที่ชัดเจนและสั้นเพื่อที่คุณจะได้ไม่ต้องเปลี่ยนแปลงมากเกินไปในการทดสอบ (ซึ่งอาจกลายเป็นแหล่งที่มาของเสียงรหัสขนาดใหญ่ถ้าทำอย่างอื่น) นี้สนับสนุนSingle รับผิดชอบหลักการ
3. สิ่งนี้อาจเป็นที่ถกเถียงกัน แต่หลักการแยกส่วนติดต่ออนุญาตให้คลาสพึ่งพาอินเทอร์เฟซที่เบากว่าซึ่งทำให้การเยาะเย้ยง่ายต่อการติดตามและทำความเข้าใจเพราะคุณไม่ต้องถามว่า ที่สำคัญยิ่งกว่านั้นคือคุณไม่มีทางเลือกมากมายในการตัดสินใจเลือกวิธีการเยาะเย้ย สิ่งนี้เป็นสิ่งที่ดีเมื่อคุณไม่ต้องการไปดูรหัสทั้งหมดของชั้นเรียนก่อนที่จะทดสอบและใช้การลองผิดลองถูกเพื่อทำความเข้าใจพื้นฐานเกี่ยวกับวิธีการใช้งาน

การปฏิบัติตามหลักการ Open / Closed อาจช่วยให้การทดสอบที่เขียนขึ้นหลังจากรหัสดีขึ้นเนื่องจากจะช่วยให้คุณสามารถแทนที่การเรียกบริการภายนอกในคลาสการทดสอบที่ได้มาจากคลาสที่อยู่ภายใต้การทดสอบ ใน TDD ฉันเชื่อว่านี่ไม่ได้เป็นไปตามหลักการอื่น ๆ แต่ฉันอาจเข้าใจผิด

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

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

ไม่

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

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

มันยังให้ความเข้าใจที่แข็งแกร่งมากขึ้นของรูปแบบการออกแบบส่วนใหญ่ โดยเฉพาะรูปแบบกลยุทธ์

ใช่ : TDD เป็นเทคนิคการออกแบบที่ดีเป็นหลัก (และเป็นเทคนิคการทดสอบรองเท่านั้น) มันช่วยได้มากในการบรรลุหลักการที่มั่นคงแม้ว่าตัวอย่าง (พยาธิวิทยา) ของ TDD ที่มีกลิ่นโค้ดจำนวนมากก็ยังคงเป็นไปได้

การเชื่อมต่อระหว่าง TDD และหลักการที่มั่นคงมีความไม่แน่นอน (ด้วยกับข้อสรุปข้างต้น) ในพอดคาสต์ hanselminute นี้ดีชื่อ "ทดสอบขับเคลื่อนการพัฒนาคือการออกแบบ - คำสุดท้ายบน TDD"