คุณต้องการทดสอบโค้ดบางส่วน แต่คุณติดขัด บางทีคุณอาจไม่แน่ใจว่าอินเทอร์เฟซของวัตถุควรเป็นอย่างไร บางทีคุณอาจฟุ้งซ่านไปกับวันฤดูร้อนที่มีแดดจัด คุณอาจไม่แน่ใจว่าคุณสามารถทดสอบสิ่งที่คุณคิดจะสร้างได้ หรือคุณอาจจะผัดวันประกันพรุ่งเพราะตอนนี้คุณไม่อยากเขียนแบบทดสอบ คุณจะได้รับประโยชน์จาก TDD ได้อย่างไรเมื่อคุณไม่รู้สึกอยาก TDD
การสร้างต้นแบบหรือสร้างต้นแบบเพื่อทิ้ง
“ในกรณีที่มีการใช้แนวคิดระบบใหม่หรือเทคโนโลยีใหม่ เราต้องสร้างระบบทิ้งไป เพราะแม้แต่การวางแผนที่ดีที่สุดก็ยังไม่ฉลาดพอที่จะทำให้ถูกต้องในครั้งแรก ดังนั้นวางแผนที่จะโยนทิ้งไป คุณจะยังไงก็ตาม” – เฟร็ด บรู๊คส์
บางครั้ง เมื่อฉันเริ่มคุณสมบัติใหม่ ฉันจะรู้สึกเป็นอัมพาตเมื่อนึกถึงการเขียนการทดสอบครั้งแรก มีการตัดสินใจมากมายที่ต้องทำเกี่ยวกับรูปลักษณ์ของ API รูปแบบและแนวทางปฏิบัติที่เหมาะสมที่สุด และควรเข้ากันได้อย่างไร
ฉันมีสองสามวิธีที่จะเริ่มต้นเมื่อฉันติดอยู่แบบนั้น การสร้างต้นแบบเป็นอีกสิ่งหนึ่ง
เมื่อคุณเขียนต้นแบบ คุณควรคิดว่ามันเหมือนภาพร่าง ระดมสมองและลองทำสิ่งต่างๆ อย่าเพิ่งกังวลกับการทดสอบหรือ TDD ให้สำรวจการตัดสินใจที่คุณทำได้ยากด้วยโค้ด ลองใช้รูปแบบสองสามรูปแบบ และดูว่ารูปแบบใดเหมาะสมกับคุณลักษณะที่คุณพยายามออกแบบ ค้นหาว่าส่วนใดของแอปที่สั่นคลอน ต้องการความคิดมากกว่านี้ และสิ่งที่คุณกังวลโดยไม่มีเหตุผลที่แท้จริง
จากนั้น โยนทิ้งแล้วสร้างใหม่ คราวนี้ ใช้ TDD และความรู้ใหม่ของคุณเกี่ยวกับวิธีการสร้างคุณลักษณะให้ดีที่สุด
คุณรู้เมื่อคุณเรียกใช้ git checkout -f . โดยไม่ได้ตั้งใจ หลังจากที่คุณเขียนอะไรบางอย่างแล้วรู้สึกว่าคุณเพิ่งโดนเตะที่ท้อง? แต่แล้วคุณคิดว่า มันต้องถูกสร้างขึ้น ดังนั้น ฉันเดาว่าฉันจะทำอีกครั้ง และมันกลับกลายเป็นว่าดีกว่าที่เคยทำครั้งแรกมาก สิ่งนี้เป็นจริงด้วยการสร้างต้นแบบขึ้นใหม่ ตอนนี้คุณมีแนวคิดที่ชัดเจนแล้วว่าฟีเจอร์นี้สามารถ ฟังนะ TDDing ฟีเจอร์นั้นจะง่ายขึ้นมาก
ย้อนกลับ TDD
คุณเคยเจอสถานการณ์ที่คุณรู้วิธีสร้างบางสิ่ง แต่คุณไม่รู้วิธีเขียนแบบทดสอบก่อนหรือไม่? หรืออาจเป็นการเปลี่ยนวิธีการเพียงบรรทัดเดียว แต่อาจต้องมีการปรับแต่ง คุณจึงไม่ต้องการล็อกมันด้วยการทดสอบก่อนที่คุณจะรู้ว่าการเปลี่ยนแปลงนั้นจะเป็นอย่างไร
มีขั้นตอนง่ายๆ ที่ช่วยได้มากในสถานการณ์เหล่านี้:
- เขียนโค้ดโดยไม่ต้องทดสอบ
- เขียนการทดสอบโค้ด ตรวจสอบให้แน่ใจว่าผ่าน
- แสดงความคิดเห็น รหัสที่คุณเขียนหรือเปลี่ยนกลับไฟล์ที่คุณทำการเปลี่ยนแปลงรหัส
- ทำการทดสอบอีกครั้ง ตรวจสอบให้แน่ใจว่ามันล้มเหลว
- เขียนโค้ดอีกครั้ง ทำการทดสอบของคุณ ตรวจสอบให้แน่ใจว่าพวกเขาผ่าน
- ปรับโครงสร้างโค้ดใหม่ ใช้ประโยชน์จากการทดสอบใหม่ของคุณ
ฉันคิดว่านี่เป็น Reverse TDD หรือ เขียว-แดง-เขียว-รีแฟคเตอร์ คุณจะไม่ได้รับส่วน "การออกแบบที่ขับเคลื่อนด้วยการทดสอบ" ของ TDD แต่คุณจะยังเห็นการทดสอบของคุณล้มเหลวเมื่อโค้ดของคุณใช้งานไม่ได้ นั่นสำคัญ เพราะคุณไม่สามารถเชื่อถือการทดสอบที่ไม่ล้มเหลวอย่างน้อยหนึ่งครั้งได้
Reverse TDD มักจะทำงานได้ดีที่สุดกับการเปลี่ยนแปลงเล็กๆ น้อยๆ ที่ไม่ต้องการการออกแบบมากนัก คิดว่าการแก้ไขข้อผิดพลาดหรือการเปลี่ยนแปลงที่แปลเป็นภาษาบรรทัดเดียว เมธอด หรือคลาส แต่ฉันใช้เทคนิคนี้บ่อยมาก โดยเฉพาะการเปลี่ยนแปลงเล็กๆ น้อยๆ ที่ฉันยังคงเล่นอยู่
เกมจับคู่
เกมจับคู่เป็นวิธีที่ยอดเยี่ยมในการแบ่งออกจากรูทีน Red-Green-Refactor เมื่อคุณมีผู้พัฒนารายอื่นอยู่ด้วย มันทำงานดังนี้:
- ค้นหาพันธมิตร
- คุณเขียนบททดสอบที่จะพัง
- คู่ของคุณพยายามแก้ไขการทดสอบนั้นด้วยรหัสที่ง่ายที่สุด
- คุณเขียนการทดสอบอื่นที่จะล้มเหลวในโค้ดนั้น
- คู่ของคุณเขียนโค้ดที่จะผ่านการทดสอบนั้น
- ซ้ำ…
- เมื่อการทดสอบเป็นสีเขียว คุณสามารถเลือกจัดโครงสร้างโค้ดใหม่แทนการเขียนการทดสอบ
- หลังจากปรับโครงสร้างใหม่แล้ว ให้สลับตำแหน่งผู้ทดสอบและตัวเข้ารหัส
ฉันจะแจ้งให้คุณทราบเป็นความลับ:การเล่นเกมจับคู่โดยใช้เครื่องคำนวณคะแนนโบว์ลิ่งเป็นวิธีที่ฉันเรียนรู้ TDD ในตอนแรก มันจะช่วยให้คุณฝึกเขียนโค้ดอย่างง่ายโดยอิงจากการทดสอบที่ล้มเหลว และเขียนการทดสอบเหล่านั้นเพื่อเริ่มต้น นักพัฒนาทั้งสองจะได้เรียนรู้มากมายเกี่ยวกับรูปแบบการเขียนโค้ดของกันและกันและเทคนิคที่ชื่นชอบ และคุณจะไหลลื่นแทบจะในทันที ซึ่งหมายความว่าคุณจะรู้สึกดีเมื่อทำเสร็จแล้ว
คุณอาจสร้างโค้ดได้ไม่เร็วนัก แต่สนุกมากและเป็นประสบการณ์การเรียนรู้ที่ยอดเยี่ยม
อยู่อย่างสนุกสนานและทดลอง
TDD ไม่ควรเป็นความเชื่อ มีวิธีที่คุณสามารถเล่นกับแนวคิด TDD หลักที่จะนำคุณไปสู่สถานที่ที่น่าสนใจจริงๆ และคุณอาจจะได้โค้ดที่ดีกว่านี้
เลยทดลอง ลองวิธีใหม่ในการเขียนโค้ดและ TDD ดูว่าพวกเขาทำให้คุณรู้สึกอย่างไร และคุณลงเอยด้วยรหัสประเภทใด และค้นพบความสนุกและความลื่นไหลในงานที่คุณทำในแต่ละวันอีกครั้ง
