นักพัฒนาที่ดีรู้ว่าควรทดสอบโค้ดของตน แต่บ่อยครั้งที่การทดสอบถูกข้าม เร่ง หรือไม่เคยเริ่มเลย มีกับดักทั่วไปบางอย่างที่ฉันเคยเห็นผู้คนตกหล่น และพวกเขาจะทำลายแรงจูงใจของคุณในการทดสอบทุกครั้ง
1. ฉันควรใช้ RSpec หรือไม่ แตงกวา? คาปิบาร่า? น้อยที่สุด?
เมื่อคุณเริ่มโครงการใหม่ มันคือทาง ง่ายเกินไปที่จะใช้เวลามากในการพยายามเลือกเครื่องมือที่ดีที่สุด การผัดวันประกันพรุ่งแบบนี้ปกปิดความจริงที่ว่าคุณ ไม่รู้ว่าจะเริ่มต้นที่ไหน และจนกว่าคุณจะเลือกเครื่องมือ คุณจะ รู้สึก มีประสิทธิผลโดยไม่ต้อง เป็น มีประสิทธิผล
ให้เลือกสแต็กที่คุณรู้จักดีที่สุดแทน หากคุณไม่เคยมีประสบการณ์กับสแต็กทดสอบใด ๆ เลย ให้เริ่มต้นโดยเริ่มจากสิ่งที่ Rails มอบให้คุณ คุณสามารถเพิ่มได้อีกในภายหลัง การทดลองใช้เครื่องมือใหม่ๆ นั้นไม่ผิด แต่มาก ควรแนะนำพวกเขาเมื่อเวลาผ่านไป ในขณะที่คุณทำความรู้จักโครงการและเวิร์กโฟลว์ของคุณมากขึ้น
2. ฉันจะเริ่มต้นด้วยการทดสอบหน่วยหรือไม่ การทดสอบการทำงาน? การทดสอบการรวมระบบ?
เมื่อคุณเริ่มโครงการ คุณควรมีความคิดว่าควรสร้างคุณลักษณะหรือหน้าจอใดก่อน นี่เป็นจุดเริ่มต้นที่ดี! เลือกสิ่งแรกจากรายการคุณสมบัติของคุณและเขียนการทดสอบการรวมที่ล้มเหลว สิ่งนี้ควรบอกคุณว่าตัวควบคุมและเส้นทางประเภทใดที่คุณขาดหายไป ซึ่งหมายความว่าคุณต้องเขียนการทดสอบการทำงานที่ล้มเหลวบางอย่าง ผู้ควบคุมต้องการข้อมูลและตรรกะในการทำงาน ดังนั้นคุณจะต้องเขียนการทดสอบหน่วยและแบบจำลองของคุณต่อไป จากนั้น เมื่อคุณผ่านการทดสอบหน่วยของคุณ การทดสอบการใช้งานควรผ่าน และการทดสอบการรวมก็ควรเช่นกัน ตอนนี้คุณสามารถไปยังคุณลักษณะถัดไปได้
หากคุณมีขั้นตอนการทดสอบที่มีการกำหนดขั้นตอนถัดไปไว้เสมอ การมีแรงจูงใจอยู่เสมอจะง่ายขึ้นมาก หากคุณไม่ต้องตัดสินใจ ก็มีโอกาสน้อยที่การผัดวันประกันพรุ่งจะเล็ดลอดเข้ามา
3. ฉันไม่รู้วิธีทดสอบรหัสเครือข่าย ยูทิลิตี้บรรทัดคำสั่ง หรืองาน rake!
สิ่งที่ง่ายที่สุดที่จะทำที่นี่คือการย้ายโค้ดออกจากไฟล์หรือคลาสที่ยากต่อการทดสอบและไปยังออบเจกต์ใหม่ที่ง่ายต่อการทดสอบ ด้วยวิธีนี้ สิ่งที่ยากต่อการทดสอบจะสร้างและส่งพารามิเตอร์ไปยังวัตถุใหม่ของคุณ
แน่นอน คุณ ยังคง มีสิ่งดั้งเดิมที่ยากต่อการทดสอบ แต่ตอนนี้อาจเป็นโค้ดเพียงไม่กี่บรรทัด และน่าจะง่ายกว่าที่จะดึงหรือปลอมออก
4. “โครงการใกล้เสร็จแล้ว ตอนนี้ฉันแค่ต้องเขียนแบบทดสอบ!”
นักพัฒนาทุกคนที่ฉันได้พบ กระหาย รหัสการจัดส่ง หากการทดสอบเป็นสิ่งสุดท้ายที่ต้องทำก่อนที่คุณจะสามารถจัดส่งได้ คุณจะต้องเขียนจำนวนการทดสอบขั้นต่ำที่คุณต้องใช้เพื่อให้มั่นใจว่าโค้ดใช้งานได้จริง หากคุณติดเป็นนิสัยนี้ คุณจะเริ่มเห็นว่าการทดสอบนั้นน่ารำคาญแทนที่จะมีประโยชน์ และจะยากขึ้นมากที่จะกระตุ้นให้ตัวเองเขียน
สิ่งหนึ่งที่ฉันชอบเกี่ยวกับ TDD คือมันผสมผสานการทดสอบกับการออกแบบและการเขียนโค้ด ซึ่งหมายความว่าคุณเริ่มเห็นการทดสอบ เหมือน การเข้ารหัสซึ่งทำให้สนุกมากขึ้น (และคุณได้รับประโยชน์จากการทดสอบ จำนวนมาก ก่อนหน้านี้)
5. ถ้าฉันทำผิดล่ะ
ชุมชน Ruby เป็นที่รู้จักในด้านคุณภาพของโค้ด การทดสอบหน่วย และหลักการออกแบบเชิงวัตถุ นี้เป็นสิ่งที่ดี! น่าเสียดาย เป็นเรื่องปกติที่จะรู้สึกกดดันอย่างมากในการจัดส่งโค้ดที่สมบูรณ์แบบโดยครอบคลุมการทดสอบ 100% ในการลองครั้งแรก
ซึ่งทำให้ยากต่อการเริ่มต้นโครงการ โดยเฉพาะโอเพ่นซอร์ส ซึ่งคุณรู้ว่าคนอื่นจะเห็นโค้ด ผู้คนจะพูดอะไรหากพวกเขาเห็นว่าไม่เป็นไปตามหลักการ SOLID ทั้งหมด แต่มีบางสิ่งที่ฉันได้เรียนรู้ที่ช่วยรับมือกับแรงกดดันนี้:
- นักพัฒนาที่ดีทุกคน เขียนโค้ดที่พวกเขาอายในภายหลัง
- โค้ดดีๆ ที่จัดส่งได้ดีกว่าโค้ดที่สมบูรณ์แบบที่ไม่มีอยู่จริง
- บางคนเป็นแค่คนโง่และจะล้อเลียนโค้ดของคุณ นี่มันแย่จริงๆ มันทำลายทั้งสัปดาห์ของฉัน แต่นักพัฒนาที่ดีต้องการช่วยเหลือ คุณแทนที่จะวิพากษ์วิจารณ์คุณ และฉันพนันได้เลยว่าถ้าคุณแสดงโค้ดนั้นให้กับฮีโร่ในการเขียนโปรแกรมของคุณ พวกเขาจะไม่ล้อเลียนมันหรอก พวกมันจะช่วยให้คุณทำให้มันดีขึ้นได้
คุณสังเกตเห็นอะไรอีกบ้าง
คุณตกอยู่ในกับดักใดต่อไปนี้ อะไรช่วยให้คุณดึงตัวเองออกมา? และมีอะไรที่ฉันไม่ได้พูดถึงว่าคุณสังเกตเห็นไหม
หากคุณจำตัวเองในกับดักเหล่านี้ได้ คุณจะทำอย่างไรเพื่อเอาตัวรอด
