(สัปดาห์นี้ฉันอยู่ที่ชิคาโกเพื่อเข้าร่วม RailsConf ถ้าคุณเห็นฉันแถวๆ นี้ ทักทายฉันสิ ฉันอยากพบคุณ ฉันอายุมากกว่าในรูปในแถบด้านข้าง)
ผู้อ่านถามคำถามที่ดีเกี่ยวกับการทดสอบในความคิดเห็นในบทความของฉัน:
ฉันรู้ว่าฉันต้องทำให้ "มู่เล่ TDD" เคลื่อนที่ด้วย แต่ TDD นั้นไม่คุ้นเคยกับฉันมาก คุณมีคำแนะนำใดๆ เกี่ยวกับวิธีที่ดีที่สุดในการเริ่มต้นด้วย RSpec หรือเป็นเพียงการ "เข้าไปที่นั่นและแฮ็กออกไป"
ฉันก็เลยตอบไปว่า:
หากคุณไม่ถนัดด้านใดด้านหนึ่ง คุณอาจพบว่า minitest นั้นง่ายต่อการเริ่มต้น เป็น "วิธีการและชั้นเรียน" อีกเล็กน้อย คุณจึงสามารถมุ่งเน้นไปที่การเรียนรู้และฝึก TDD ได้อย่างสมบูรณ์โดยไม่ต้องเรียนรู้ไวยากรณ์ใหม่
Rails มีคำแนะนำที่ดีพอสมควรเกี่ยวกับคำศัพท์ในการทดสอบ การยืนยัน และวิธีการเรียกใช้การทดสอบโดยทั่วไปใน Rails
วิธีที่ดีที่สุดในการเรียนรู้ TDD คือการฝึกฝน นี่คือขั้นตอนที่คุณควรปฏิบัติตาม:
- เขียนการทดสอบที่ถือว่าโค้ดที่คุณต้องการมีอยู่แล้ว
- เรียกใช้การทดสอบ ตรวจสอบให้แน่ใจว่าการทดสอบใหม่ของคุณล้มเหลว
- เขียนโค้ดที่ง่ายที่สุดที่จะผ่านการทดสอบ อย่าเป็นนามธรรมหรือจัดองค์ประกอบใหม่ที่นี่มากเกินไป
- ทำการทดสอบ ตรวจสอบให้แน่ใจว่าการทดสอบใหม่ของคุณผ่าน
- จัดโครงสร้างโค้ดใหม่เพื่อลบการซ้ำซ้อน (หรือทำให้โค้ดมีความชัดเจนมากขึ้น)
- ทำการทดสอบอีกครั้ง (เพื่อให้แน่ใจว่าการทดสอบยังคงผ่าน)
- กลับไปที่ขั้นตอนที่ 1
ขณะที่คุณกำลังฝึก TDD คุณควรถามตัวเองต่อไปว่า:ฉันอยู่ในขั้นตอนไหน? ฉันข้ามขั้นตอนหรือไม่? ขั้นตอนต่อไปคือ? (คุณควรอยู่ในขั้นตอนใดขั้นตอนหนึ่งเหล่านี้เสมอ) สิ่งนี้จะช่วยให้คุณมาถูกทาง ซึ่งสำคัญมาก ขณะที่คุณกำลังเรียนรู้สิ่งใหม่ “การฝึกฝนทำให้ถาวร” ดังนั้นคุณจึงไม่อยากฝึกผิด!
แต่ยัง อนุญาตให้ตัวเองทำเรื่องยุ่งๆ . คุณกำลังเรียนรู้ ไม่เป็นไร! มันจะง่ายขึ้นมากเมื่อคุณทำบ่อยๆ
Eric Steele ผู้ซึ่งกำลังเขียนหนังสือเกี่ยวกับการทดสอบอยู่เช่นกัน ได้กล่าวถึงประเด็นสำคัญที่ฉันพลาดไป:
ส่วนของ TDD ที่ถูกทิ้งไว้เบื้องหลังคือจำนวนการวางแผนที่เกิดขึ้นก่อนขั้นตอนที่ 1
การทดสอบเป็นที่ที่ข้อกำหนดของแอปตรงตามการใช้งานตามแผนของคุณ การพัฒนาที่ขับเคลื่อนด้วยการทดสอบขึ้นอยู่กับการรู้ว่าแอปควรทำอย่างไร และถือว่าคุณมีแนวคิดว่าต้องทำอย่างไร
เมื่อเราเริ่มสร้างด้วย Rails ครั้งแรก เราไม่รู้อะไรมาก เราใช้เวลามากในการเขียนโค้ดทดลองจนกว่าเราจะได้ผลลัพธ์ที่ใกล้เคียงกับสิ่งที่เรากำลังมองหา คุณทำสิ่งนี้น้อยลงเมื่อคุณเรียนรู้มากขึ้น ฉันคิดว่านี่คือเหตุผลที่ TDD เริ่มต้นด้วย 'เขียนการทดสอบ' ไม่ใช่ 'ค้นหาว่าคุณกำลังสร้างอะไร' ในขณะที่คุณทำการทดสอบ คุณมีประสบการณ์มากมายภายใต้เข็มขัดของคุณ
ฉันจะเพิ่มขั้นตอนเหล่านี้ก่อน "เขียนการทดสอบ":
- ระดมสมอง ให้เหตุผล และคัดเลือกข้อกำหนด หลีกเลี่ยงการเข้ารหัสในทุกกรณี
- วางแผนและออกแบบโค้ดของคุณที่ตรงตามข้อกำหนดเหล่านั้น
- คนจรจัดกับรหัสเพื่อตอบคำถามที่ไม่รู้จัก แต่ให้แยกรหัสนั้นไว้
คำแนะนำของฉัน:
- มุ่งเน้นการวางแผนมากกว่ารูปแบบไวยากรณ์
- ลดขนาดเครื่องมือของคุณ (ฉันพบว่า minitest/fixtures มีประโยชน์จริงๆ)
- ฝึกฝน ฝึกฝน ฝึกฝน
เช่นเดียวกับสิ่งอื่นใด การเริ่มต้นใช้งาน TDD นั้นต้องอาศัยการฝึกฝนและความสามารถในการแก้ไขตัวเอง (หรือมีคนอยู่ใกล้ๆ เพื่อแก้ไขคุณ) หากคุณสามารถทำตามขั้นตอนที่กึ่งแข็งกร้าวได้ไม่กี่ขั้นตอน และจำไว้ว่าคุณอยู่ในขั้นตอนใด TDD จะรู้สึกเป็นธรรมชาติสำหรับคุณในไม่ช้า
