วิธีการที่เฉพาะเจาะจงในการทดสอบนั้นมีค่ามากน้อยเพียงใดนั้นขึ้นอยู่กับความสำคัญของภารกิจที่ระบบภายใต้การพัฒนาอยู่ สคริปต์สมุดเยี่ยมสำหรับเว็บไซต์ของคุณอาจไม่ได้รับการพิจารณาว่าเป็นภารกิจที่สำคัญ แต่ถ้าเว็บไซต์นั้นทำงานได้อาจถูกบุกรุกโดยข้อผิดพลาดที่อนุญาตการป้อนข้อมูลที่ไม่มีการกรองไปยังฐานข้อมูลและเว็บไซต์นั้นให้บริการที่สำคัญบางอย่าง สำคัญสำหรับสคริปต์สมุดเยี่ยมชมที่จะทดสอบอย่างละเอียด เช่นเดียวกันกับเฟรมเวิร์ก / รหัสห้องสมุด หากคุณพัฒนาเฟรมเวิร์กที่มีบั๊กแอปพลิเคชันทุกตัวที่ใช้คุณสมบัติเฟรมเวิร์กนั้นก็จะมีบั๊กเหมือนกัน
การพัฒนาที่ขับเคลื่อนด้วยการทดสอบช่วยเพิ่มความปลอดภัยให้กับคุณเป็นพิเศษเมื่อพูดถึงการทดสอบ หากคุณเขียนการทดสอบไปด้านข้างหรือหลังรหัสที่คุณต้องการทดสอบมันมีความเสี่ยงที่คุณจะได้รับการทดสอบที่ผิด หากคุณเขียนการทดสอบทั้งหมดก่อนว่าวิธีการทำงานของรหัสนั้นไม่สามารถมีอิทธิพลต่อสิ่งที่คุณเขียนการทดสอบภายในได้ดังนั้นจึงมีความเป็นไปได้น้อยกว่าที่คุณจะเขียนการทดสอบโดยไม่ตั้งใจซึ่งคิดว่าผลลัพธ์ที่ผิดพลาดนั้นถูกต้อง
การพัฒนาที่ขับเคลื่อนด้วยการทดสอบยังกระตุ้นให้นักพัฒนาของคุณเขียนโค้ดที่ง่ายต่อการทดสอบเพราะพวกเขาไม่ต้องการให้ตัวเองทำงานได้มากขึ้น! รหัสที่ทดสอบได้ง่ายมีแนวโน้มที่จะเป็นรหัสที่เข้าใจง่ายนำมาใช้ซ้ำและดูแลรักษาได้
และการบำรุงรักษาคือที่ที่คุณจะได้รับรางวัลของ TDD ความพยายามในการเขียนโปรแกรมส่วนใหญ่ที่เกิดขึ้นกับซอฟต์แวร์นั้นเกี่ยวข้องกับการบำรุงรักษา ซึ่งหมายถึงการเปลี่ยนแปลงรหัสสดเพื่อมอบคุณสมบัติใหม่แก้ไขข้อบกพร่องหรือปรับให้เข้ากับสถานการณ์ใหม่ เมื่อทำการเปลี่ยนแปลงดังกล่าวคุณต้องการให้แน่ใจว่าการเปลี่ยนแปลงที่คุณทำมีผลตามที่ต้องการและที่สำคัญกว่านั้นคือสิ่งเหล่านั้นไม่มีผลกระทบที่คาดไม่ถึง หากคุณมีชุดทดสอบเต็มรูปแบบสำหรับรหัสของคุณคุณสามารถตรวจสอบได้อย่างง่ายดายว่าการเปลี่ยนแปลงใด ๆ ที่คุณทำไม่ได้เป็นการทำลายอย่างอื่นและหากการเปลี่ยนแปลงที่คุณทำนั้นทำลายอย่างอื่นคุณก็สามารถหาสาเหตุได้อย่างรวดเร็ว ผลประโยชน์ระยะยาว
คุณพูดสิ่งต่อไปนี้ในคำถามของคุณ:
ฉันเห็นประโยชน์บางอย่างในการเขียนข้อสอบสำหรับบางสิ่ง แต่มีน้อยมาก และในขณะที่ฉันชอบความคิดในการเขียนการทดสอบครั้งแรกฉันพบว่าฉันใช้เวลามากขึ้นในการพยายามดีบั๊กการทดสอบเพื่อให้พวกเขาพูดในสิ่งที่ฉันหมายถึงจริงๆมากกว่าการดีบักรหัสจริง อาจเป็นเพราะรหัสทดสอบมักจะมีความซับซ้อนมากกว่ารหัสที่ทดสอบ ฉันหวังว่านี่เป็นเพียงประสบการณ์ที่ไม่มีเครื่องมือที่มีอยู่ (rspec ในกรณีนี้)
ดูเหมือนว่าสิ่งนี้จะแนะนำให้ฉันรู้ว่าคุณไม่ได้รับการทดสอบ การทดสอบหน่วยควรจะง่ายมากเพียงลำดับของการเรียกเมธอดตามด้วยการยืนยันเพื่อเปรียบเทียบผลลัพธ์ที่คาดหวังกับผลลัพธ์จริง พวกมันมีความเรียบง่ายเพราะบั๊กในการทดสอบของคุณจะเป็นหายนะและถ้าคุณแนะนำลูปการแยกย่อยหรือโปรแกรมอื่น ๆ ที่ควบคุมการทดสอบแล้วมีแนวโน้มว่าการทดสอบจะมีบั๊กที่แนะนำ หากคุณใช้การทดสอบการดีบักเป็นจำนวนมากแสดงว่าการทดสอบของคุณซับซ้อนเกินไปและคุณควรทำให้การทดสอบนั้นง่ายขึ้น
หากการทดสอบไม่สามารถทำให้เข้าใจง่ายกว่าข้อเท็จจริงเพียงอย่างเดียวแสดงให้เห็นว่ามีบางอย่างผิดปกติกับรหัสที่ทดสอบ ตัวอย่างเช่นหากชั้นเรียนของคุณมีวิธีการยาววิธีการที่มีจำนวนมากถ้า / elseif / อื่นหรือสลับคำสั่งหรือวิธีการจำนวนมากที่มีการโต้ตอบที่ซับซ้อนซึ่งกำหนดโดยสถานะปัจจุบันของชั้นเรียนการทดสอบจะต้องซับซ้อนมาก เพื่อให้ครอบคลุมรหัสเต็มและทดสอบเหตุการณ์ทั้งหมด หากชั้นเรียนของคุณมีรหัสอ้างอิงที่ยากในชั้นเรียนอื่น ๆ สิ่งนี้จะเพิ่มจำนวนของห่วงที่คุณจะต้องข้ามไปเพื่อทดสอบรหัสของคุณอย่างมีประสิทธิภาพ
หากคุณรักษาคลาสของคุณให้มีขนาดเล็กและเน้นไปที่สูงด้วยวิธีการสั้น ๆ ที่มีเส้นทางการดำเนินการไม่กี่และพยายามที่จะกำจัดสถานะภายในจากนั้นการทดสอบจะง่าย และนี่คือจุดเริ่มต้นของเรื่อง รหัสที่ดีนั้นง่ายต่อการทดสอบโดยเนื้อแท้ หากรหัสไม่ง่ายต่อการทดสอบอาจมีบางอย่างผิดปกติ
การทดสอบหน่วยการเขียนเป็นสิ่งที่มีประโยชน์สำหรับคุณในระยะยาวและการหลีกเลี่ยงการทดสอบนั้นเป็นการเก็บปัญหาไว้ใช้ในภายหลัง คุณอาจไม่คุ้นเคยกับแนวคิดเรื่องหนี้ทางเทคนิค แต่มันใช้งานได้ดีเหมือนหนี้ทางการเงิน ไม่เขียนการทดสอบไม่แสดงความคิดเห็นรหัสการเขียนในการอ้างอิงรหัสยากและอื่น ๆ เป็นวิธีที่จะเป็นหนี้ คุณ "ยืม" เวลาด้วยการตัดมุมก่อนและสิ่งนี้อาจช่วยให้คุณถึงกำหนดเวลาที่แน่นหนา แต่เวลาที่คุณบันทึกไว้ก่อนหน้านี้ในโครงการคือเงินกู้ ในแต่ละวันที่ผ่านไปโดยไม่ต้องทำความสะอาดโค้ดแสดงความคิดเห็นอย่างถูกต้องหรือสร้างชุดทดสอบจะทำให้คุณเสียค่าใช้จ่าย อีกต่อไปมันจะไปดอกเบี้ยที่สะสมมากขึ้น ในที่สุดคุณจะค้นพบรหัสของคุณกลายเป็นเรื่องยุ่งเหยิงที่คุณไม่สามารถเปลี่ยนแปลงได้โดยไม่ทำให้เกิดผลกระทบที่ไม่ตั้งใจ
คุณสามารถคิดถึงการเขียนแบบทดสอบหน่วยต้นและทำให้พวกเขาทันสมัยเป็นรูปแบบของ "เครดิตทางเทคนิค" คุณกำลังวางเวลาในธนาคารโดยการใช้จ่ายก่อนเวลาในโครงการตามแนวปฏิบัติที่ดี คุณจะได้รับความสนใจในการมองอนาคตนี้ในภายหลังเมื่อคุณเข้าสู่ขั้นตอนการบำรุงรักษาของโครงการ เมื่อคุณต้องการเปลี่ยนแปลงคุณสามารถตรวจสอบความถูกต้องของการเปลี่ยนแปลงได้อย่างง่ายดายและไม่มีผลข้างเคียงใด ๆ ที่ไม่ต้องการและคุณสามารถรับการอัปเดตได้อย่างรวดเร็วโดยไม่ต้องยุ่งยาก หากข้อผิดพลาดปรากฏขึ้นคุณสามารถเพิ่มการทดสอบหน่วยใหม่ที่ใช้ข้อบกพร่องแล้วแก้ไขข้อผิดพลาดในรหัส เมื่อคุณทำการทดสอบหน่วยในครั้งต่อไปคุณจะสามารถตรวจสอบได้ว่าข้อผิดพลาดได้รับการแก้ไขและไม่ทำให้เกิดปัญหาอื่น ๆ ยิ่งไปกว่านั้นคุณจะหลีกเลี่ยง "การถดถอย"
TL: DR - ใช่พวกเขาเป็นความช่วยเหลือโลกแห่งความจริง แต่พวกเขาเป็นการลงทุน ประโยชน์จะชัดเจนขึ้นในภายหลังเท่านั้น