TDD: จะเกิดอะไรขึ้นก่อนการทดสอบครั้งแรก

ฉันเข้าใจทฤษฎีของ TDD เป็นส่วนใหญ่ แต่ฉันไม่สามารถหาวิธีเริ่มต้นได้ ฉันนั่งลงเพื่อเขียนการทดสอบหน่วยสำหรับโครงการส่วนบุคคลและตระหนักถึง . . ฉันไม่รู้ว่ากำลังทดสอบอะไรอยู่ วัตถุใดฟังก์ชันการทำงาน ฯลฯ

เช่นสมมติว่าฉันต้องการเขียนแอพเพื่อช่วยครอบครัวของเราจัดการงานบ้าน ต่อไปนี้เป็นคำถามบางข้อในใจ: ฉันจะเปลี่ยนจากแนวคิดนี้เป็นแบบทดสอบครั้งแรกได้อย่างไร ควรตัดสินใจเท่าไหร่ก่อนที่จะเริ่มและฉันจะรู้ได้มากแค่ไหนหลังจากเริ่มเขียนข้อสอบ? เมื่อใดที่ฉันต้องตัดสินใจว่าจะเก็บข้อมูลในไฟล์ข้อความหรือฐานข้อมูลหรือไม่ ฉันควรมีการทดสอบการยอมรับของผู้ใช้ก่อนที่จะเริ่ม? ฉันควรจะออกแบบ UI หรือไม่ ฉันควรจะมีสเป็คหรือไม่? (ฉันรู้ว่าอย่างน้อยคำถามตัวอย่างเหล่านี้อาจอยู่ใน "พื้นที่สีเทา")

นอกจากคำถามชื่อเรื่องเกี่ยวกับการทดสอบหน่วยแรกคุณสามารถให้ตัวอย่างของการทดสอบหน่วยแรกสำหรับโครงการเช่นโครงการตัวอย่างที่อาจมีลักษณะอย่างไร

ฉันต้องการเริ่มต้นด้วยรายการคุณลักษณะและสำหรับแต่ละคุณลักษณะเขียนเรื่องราวของผู้ใช้จากนั้นสำหรับแต่ละคำอธิบายการทดสอบการเขียนเรื่องราว

ลองนึกถึงการออกแบบสักหน่อยแล้วเลือกคำอธิบายการทดสอบแล้วเริ่มเขียนโค้ด: red-green-refactor

ทำซ้ำจนกว่าการทดสอบทั้งหมดจะผ่าน

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

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

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

ฉันต้องการเขียนแอพเพื่อช่วยครอบครัวของเราจัดการงานบ้าน

เย็น. หากแอพนั้นทำงานได้จะต้องทำอย่างไร บางทีงานบ้านอาจถูกกำหนดให้กับคนใช่มั้ย

Person fred = new Person("fred")
Chore mow = new Chore("mow the lawn");
mow.assignTo(fred);
assertEquals(fred, mow.whoIsAssigned());

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

ใช่ TDD มีปัญหานี้ นั่นเป็นเหตุผลที่ฉันแนะนำการพัฒนาพฤติกรรมขับเคลื่อน

เริ่มด้วยตนเอง เขียนสิ่งที่คล้ายกับเรื่องราวของผู้ใช้:

• ในฐานะผู้ใช้
• เมื่อฉันเลือกเพิ่มลงในรถเข็นฉันต้องการให้เพิ่มผลิตภัณฑ์ในพื้นหลังอย่างโปร่งใส
• เพื่อให้ฉันสามารถช็อปปิ้งต่อได้อย่างต่อเนื่องโดยไม่สะดุด

ตอนนี้ฟีเจอร์ใดบ้างที่สนับสนุนเป้าหมายนั้น (ส่วน 'ดังนั้น')

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

นี่คือทุกสิ่งที่คุณทำได้และควรตรวจสอบด้วยตนเอง

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

.Net มี WatiN สำหรับการสร้างเว็บเพจอัตโนมัติหรือถ้าคุณต้องการทดสอบ API ฉันขอแนะนำ Subspec เพิ่มเติมให้กับ xUnit หรือ MSpec (คุณยังสามารถทำสิ่งนี้ได้ด้วยกรอบการทดสอบใด ๆ เพียงแค่ทำให้การตั้งชื่อการทดสอบของคุณง่ายขึ้น ที่สนับสนุนรูปแบบการคิดนี้)

Ruby มีแตงกวาสำหรับการทดสอบระบบอัตโนมัติและ rspec สำหรับการทดสอบ API ระดับล่าง

Javascript มี jasmine และ qUnit

dot dot dot

ฉันจะไปจากความคิดนี้ไปยังการทดสอบครั้งแรกของฉันได้อย่างไร ควรตัดสินใจเท่าไหร่ก่อนที่จะเริ่มและฉันจะรู้ได้มากแค่ไหนหลังจากเริ่มเขียนข้อสอบ?

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

จากนั้นแบ่งย่อยเรื่องราวเป็นงานบางส่วน (เช่นสร้างโครงการใน Eclipse ตั้งค่าที่เก็บรหัส) เมื่อคุณไปที่งานเขียนโค้ดเขียนการทดสอบครั้งแรกของคุณ

เมื่อใดที่ฉันต้องตัดสินใจว่าจะเก็บข้อมูลในไฟล์ข้อความหรือฐานข้อมูลหรือไม่

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

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ TDD ฉันอยากจะแนะนำTest Driven Development โดยตัวอย่างโดย Kent Beck นอกจากนี้เขายังมีscreencast TDDที่ติดตามการพัฒนาของห้องสมุดที่ไม่สำคัญในรูปแบบ TDD บริสุทธิ์พร้อมคำอธิบายโดย Kent ในทุกขั้นตอนในกระบวนการ ฉันคิดว่ามันเป็นตัวอย่างที่ดีของ TDD ในทางปฏิบัติแม้ว่ามันจะกระทำโดยสภาพแวดล้อมที่จำเป็น

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

ล้างทำซ้ำ ฯลฯ

สำหรับฉันการคิดเกี่ยวกับวิธีทดสอบบิตที่สำคัญและเป็นสิ่งที่สามารถขับเคลื่อนการออกแบบของคุณ