หน่วยทดสอบแนวปฏิบัติที่ดีที่สุดสำหรับหน่วยทดสอบ newbie

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

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

ฉันแค่สงสัยว่าใครสามารถให้คำแนะนำที่ดี:

1. ฉันควรจะดูการทดสอบหน่วยในช่วงเริ่มต้นของโครงการและอาจใช้แนวทาง TDD
2. ฉันควรจะเขียนข้อสอบขณะที่ทำไปหลังจากแต่ละส่วนเสร็จสมบูรณ์
3. ฉันควรทำโครงงานเสร็จแล้วเขียนการทดสอบหน่วยในตอนท้าย

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

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

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

สำหรับฉันช่วงเวลาสำคัญของยูเรก้าคือแอพ Windows ที่ฉันพยายามทดสอบ regex ซึ่งต้องใช้ฉันกรอกแบบฟอร์มสองแบบก่อนที่จะไปถึงได้ ฉันติดตั้ง NUnit และเขียนการทดสอบรอบ ๆ วิธีนั้นและดูว่าฉันประหยัดเวลาในการทดสอบได้เร็วแค่ไหน จากนั้นฉันเพิ่มการทดสอบเพิ่มเติมเพื่อจัดการกับเคสแบบขอบ และอื่น ๆ

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

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

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

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

คำตอบของฉันคือใช่แน่นอน ฉันเรียนรู้วิธีการ TDD เมื่อประมาณ 10 ปีที่แล้วหลังจากการเข้ารหัสเวลาโดยไม่ต้องทำการทดสอบ วันนี้ถ้าฉันทำอะไรสั้น ๆ (<250 loc) และแบบง่าย ๆ หรือบางสิ่งที่ถูกทิ้งฉันจะไม่ทำมัน TDD ไม่อย่างนั้นฉันทำและแม่นยำเพราะมันช่วยประหยัดเวลา

การประหยัดเวลามีสามวิธี: WTF น้อยลงการดีบั๊กน้อยกว่าและความกลัวน้อยลง อย่างแรกคือชัดเจน: คุณใช้เวลาน้อยลงมากในการสงสัยว่าสิ่งที่คุณสร้างขึ้นนั้นกำลังทำอะไรอยู่ เมื่อคุณมีปัญหาการแก้จุดบกพร่องนั้นง่ายกว่ามากเพราะก) คุณตรวจพบข้อบกพร่องที่ทดสอบแล้วและ b) ข้อบกพร่องที่ยังไม่ผ่านการทดสอบมีที่ซ่อนน้อยกว่า

สิ่งที่น่ากลัวน้อยกว่านั้นก็ยิ่งลึกซึ้ง จนกว่าคุณจะใช้เวลาสักพักในฐานรหัส TDD คุณจะไม่ทราบเลยว่าคุณใช้เวลากังวลเกี่ยวกับการเปลี่ยนแปลงที่ทำไปมากเพียงใด X ทำงานอย่างไร มันจะทำลาย Y หรือไม่? มี Z ที่อาจได้รับผลกระทบหรือไม่? ด้วย TDD ที่หายไปเพราะคุณเปลี่ยนความกลัวของคุณเป็นแบบทดสอบแล้วคอมพิวเตอร์จะทำให้เกิดความกังวลโดยอัตโนมัติ ผู้พัฒนาที่กล้าหาญเป็นผู้พัฒนาที่เร็วขึ้น

1. ฉันควรจะดูหน่วยเริ่มต้นและนำวิธีการ TDD

2. ฉันควรจะเขียนแบบทดสอบตามที่ได้ทำไปหลังจากแต่ละส่วนเสร็จสมบูรณ์หรือไม่

อย่างใดอย่างหนึ่งเหล่านี้ แต่ไม่ได้เป็นตัวเลือกที่สาม

ดังที่ @pdr ตั้งข้อสังเกตการเรียนรู้การทดสอบหน่วยที่เหมาะสมต้องใช้เวลา แน่นอนคุณต้องการที่จะใช้เวลาในการเรียนรู้ในช่วงเริ่มต้นของวงจรชีวิตของโครงการไม่ใช่สิ้นสุดเมื่อเส้นตายเริ่มขึ้นเหนือหัวของคุณ วิธีนี้คุณมีความเร็วสูงอยู่แล้วและอาจเริ่มรับผลประโยชน์ตามเวลาที่กำหนดใกล้เข้ามาเนื่องจากมีการจับแมลงส่วนใหญ่ไว้ก่อนหน้านี้ในวงจรชีวิตของโครงการ

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

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

ฉันคิดว่าสิ่งที่ดีที่สุดสำหรับมือใหม่ที่ต้องทำคือจัดการแท็กกาตบางตัวที่ให้ยืมตัวเพื่อทดสอบหน่วย ตัวอย่างเช่น; ตรวจสอบที่อยู่อีเมล TDD กลายเป็นกระแสธรรมชาติเมื่อคุณจัดการกับรหัส Katas เหล่านี้ไม่กี่ ตรวจสอบรหัส kata ต่อไปนี้สำหรับตัวตรวจสอบที่อยู่อีเมลที่ฉันพูดถึง: ตัวตรวจสอบอีเมล

สำหรับคำอธิบายว่า Code Katas คืออะไรสำหรับคนที่ไม่รู้จักให้ตรวจสอบลิงค์ต่อไปนี้: Code Katas