การพัฒนาแบบทดสอบขับเคลื่อน - โน้มน้าวใจฉัน! [ปิด]

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

1. โครงการใดที่คุณใช้ในการพัฒนาโดยใช้การทดสอบ คุณใช้สำหรับโครงการที่มีขนาดใหญ่กว่านี้หรือไม่
2. ฉันควรจะใช้มันหรือไม่? โน้มน้าวใจฉัน!

ตกลงข้อดีบางประการสำหรับ TDD:

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

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

Robert C. Martin ได้สร้างประเด็นเหล่านี้ขึ้นมา - ฉันสามารถสำรองข้อมูลได้จากประสบการณ์ของฉัน:

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

ฉันทำ TDD อยู่ตลอดเวลาไม่ว่าฉันจะผลิตหรือเล่นรหัส ฉันพบว่ามันยากที่จะเขียนโค้ดด้วยวิธีอื่นวันนี้

(ข้อจำกัดความรับผิดชอบ: ฉันแทบจะทำสิ่งใด ๆ กับ UI ดังนั้นฉันจึงไม่สามารถพูดถึง TDD สำหรับ UIs ได้)

ฉันใช้ TDD ในทุกสิ่งที่ฉันทำตั้งแต่แอพเล็ก ๆ น้อย ๆ ไปจนถึง SIP ทั้งหมด

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

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

อะไร? ไม่มีคำตอบเชิงลบ!

คำเตือน: ฉันไม่ได้ต่อต้านการทดสอบหน่วย เมื่อมีคนบอกว่า TDD ฉันคิดว่าพวกเขาหมายถึงเวอร์ชั่นที่ทำให้เกิดโรคซึ่งพวกเขากำลังเขียนแบบทดสอบก่อนที่พวกเขาจะเขียนโค้ดประมาณ 80-100% ของรหัสทั้งหมดที่พวกเขาเขียน

ฉันจะเถียง:

• มันเป็นตัวเปิดใช้งาน หากการจับปัญหาการถดถอยเป็นปัญหาใหญ่สำหรับคุณที่ TDD อัตโนมัติเต็มรูปแบบตั้งแต่เริ่มต้นดูจะคุ้มค่าการเขียนการทดสอบสำหรับรหัสชิ้นสุดท้ายที่คุณเขียนทั้งหมดอาจช่วยให้คุณไม่สนใจปัญหาที่แท้จริง

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

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

• เน้นการออกแบบ: ไม่มีทางแม้แต่นักพัฒนาที่ดีจะเขียนรหัสที่ดีที่สุดที่พวกเขาสามารถทำได้เมื่อพวกเขายังมุ่งเน้นไปที่การทดสอบ หากดูเหมือนเป็นวิธีเดียวที่คุณจะได้รับการออกแบบที่ดีฉันขอแนะนำให้ดูข้อมูลข้างต้นเกี่ยวกับ "การมุ่งเน้นไปที่ปัญหาจริง"

• การออกแบบมาโครล้มเหลว: รหัสฐานที่งานปัจจุบันของฉันเต็มไปด้วยอินเทอร์เฟซที่ไม่เคยใช้งานมากกว่าหนึ่งครั้งและการละเมิดหลักการ DRY ขั้นพื้นฐานจำนวนมากซึ่งในที่สุดฉันก็เริ่มเข้าใจเมื่อฉันตระหนักว่าผู้คนกำลังเขียนกรอบการทดสอบและการทดสอบ ทั่วไป. การทดสอบไม่ควรนำไปสู่สถาปัตยกรรมที่โง่ ไม่จริง ๆ แล้วไม่มีอะไรที่สามารถปรับขนาดได้หรือองค์กรควรค่าแก่การคัดลอกและวางไฟล์ 20 ไฟล์จากนั้นทำการเปลี่ยนแปลงที่สำคัญเพียงสองไฟล์เท่านั้น ความคิดคือการแยกความกังวลไม่แยกพวกเขาลงตรงกลาง Cruft และ abstraction ที่ไม่มีจุดหมายจะทำให้คุณเสียค่าใช้จ่ายมากกว่าที่จะไม่ครอบคลุม 95% เลยทีเดียว

• เป็นที่นิยมและผู้คนมากมายชอบมันมาก หากนั่นไม่ใช่เหตุผลที่เพียงพอที่จะคาดเดาอย่างน้อยสองครั้งและ / หรือหาทางออกจากเทคโนโลยีใด ๆ ก่อนนำมาใช้