“ การปฏิบัติที่เห็นได้ชัด” ของ TDD หมายความว่ารหัสก่อนหรือไม่

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

คุณใช้การดำเนินการอย่างง่ายได้อย่างไร เพียงแค่ใช้พวกเขา

นอกจากนี้:

บางครั้งคุณแน่ใจว่าคุณรู้วิธีการใช้งาน ไปข้างหน้า

ฉันคิดว่าสิ่งที่ผู้แต่งหมายถึงคือคุณควรทดสอบก่อนแล้วจึง "นำไปใช้" ซึ่งต่างจาก "Fake It ('Till You Make It)" และเทคนิคอื่น ๆ ซึ่งจำเป็นต้องใช้ขั้นตอนเล็ก ๆ ในขั้นตอนการปฏิบัติ หลังจากคำพูดเหล่านี้ผู้เขียนพูดถึงการได้รับ "แถบสีแดง" (การทดสอบที่ล้มเหลว) เมื่อทำ "การใช้งานที่ชัดเจน" - คุณจะได้รับแถบสีแดงโดยไม่ต้องทดสอบได้อย่างไร

แต่ฉันไม่สามารถหาคำพูดใด ๆ จากหนังสือที่บอกว่า "ชัดเจน" ยังหมายถึงการทดสอบก่อน

คุณคิดอย่างไร? เราควรทดสอบก่อนหรือหลังเมื่อมีการใช้งาน "ชัดเจน" (ตาม TDD แน่นอน) คุณรู้หรือไม่ว่าหนังสือหรือบล็อกโพสต์พูดแค่นั้น

ฉันเห็นด้วยกับการตีความของคุณ - ยังคงเป็น Refactor สีแดงสีเขียวเฉพาะบิต Refactor ที่เหลือ;)

ดังนั้นให้เขียนการทดสอบที่ล้มเหลวก่อนจากนั้นจึงใช้โซลูชันที่ชัดเจนแทนการค่อยๆสร้างการออกแบบที่ "ง่ายที่สุด"

คุณรู้หรือไม่ว่าหนังสือหรือบล็อกโพสต์พูดแค่นั้น

ฉันจะโต้แย้งว่าหนังสือของเบ็คพูดอย่างนั้น

เขาพูดต่อไป

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

คุณจะทำให้การทดสอบผ่านโดยการเขียนรหัสได้อย่างไรถ้าไม่มีอยู่ก่อนที่รหัสจะเกิดขึ้น?

เห็นได้ชัดว่าไม่มีกฎที่ยากและรวดเร็วที่นี่มีความคล่องตัวหลังจากทั้งหมดเพื่อให้เราสามารถและควรปรับตัวเมื่อเราย้ำ :)

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

นอกจากนี้อย่าลืมว่า TDD ช่วยให้คุณสามารถทดสอบอินเตอร์เฟสและการใช้งานก่อนที่จะส่งมอบรหัสสด

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

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

หากคุณพยายามที่จะได้รับความคุ้มครองที่ดีและมีคุณภาพสูงขึ้นแล้วลองทดสอบด้านอื่น ๆ เพิ่มเติมเพื่อเริ่มต้นด้วยเมื่อคุณฝึกฝน TDD มากขึ้นคุณจะพัฒนาความรู้สึกของระดับความครอบคลุมที่คุณต้องการ

ฉันได้เรียนรู้ว่าสำหรับโค้ดเล็ก ๆ น้อย ๆ นั้นไม่ควรที่จะไม่พูดถึงสิ่งใดเลย

ตัวอย่าง: ถ้าคุณมีวิธี java getter / setter ที่แมปเมธอดกับตัวแปรโลคัลสิ่งที่ไม่สำคัญสำหรับสิ่งนี้จะเป็น overkill

อาจเป็นสิ่งที่ผู้เขียนหมายถึงด้วย

> "How do you implement simple operations? Just implement them."
> "Sometimes you are sure you know how to implement an operation. Go ahead."