ประเมินว่าจะเขียนการทดสอบหน่วยหรือการทดสอบการรวมครั้งแรกในโครงการท้องฟ้าสีฟ้า / ต้นแบบ

สิ่งที่ฉันสังเกตเห็นเมื่อเร็ว ๆ นี้คือเมื่อฉันทำโครงการประเภทต่อไปนี้:

• เมื่อเริ่มต้นโครงการ
• ทำงานกับ MVP / เครื่องต้นแบบ
• การเพิ่มคุณสมบัติที่ไม่ได้กำหนดไว้ทั้งหมด
• ทำงานในโครงการขนาดเล็ก

สำหรับการอ้างอิงฉันกำลังทำงานในโครงการ Python ซึ่งปัจจุบันมีรหัส ~ 1k บรรทัดรวมถึงความคิดเห็นและช่องว่างทั้งหมด

ฉันพบว่ามันง่ายขึ้นอย่างมากในการเขียนการทดสอบการรวมการทำงานครั้งแรกทำงานบนรหัสและจากนั้นเมื่อ API ค่อนข้างแข็งจริง ๆ แล้วสามารถเพิ่มการทดสอบหน่วยได้ ประเภทของการทดสอบที่ฉันสามารถเรียกใช้ในmainฟังก์ชั่นของฉันดังนั้นพูดและมี "จบสิ้น" มากกว่าสิ่งอื่นใด

เนื่องจากการทดสอบหน่วยนั้นน่ารำคาญจริง ๆ เมื่อ API มีการเปลี่ยนแปลงอย่างรวดเร็วค่อนข้างบ่อยซึ่งเป็นกรณีเมื่อทำงานกับโครงการที่ตรงกับเกณฑ์ใด ๆ หรือส่วนใหญ่ข้างต้น

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

ฉันขาดคุณค่าของการทดสอบหน่วยของโครงการประเภทนี้ก่อนที่ API จะแข็งตัวมากขึ้นหรือไม่

ไม่คุณทำได้ดี

วัตถุประสงค์หลักสองประการของ TDD คือ:

• การกำหนดอินเตอร์เฟสโดยการใช้งานจริงแทนที่จะใช้ภายใน¹
• ครอบคลุมการทดสอบให้มากที่สุด

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

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

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

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

แต่ถ้าคุณกังวลเกี่ยวกับการสร้างการใช้งานจากบนลงล่างและ buttom-up จุด bullet แรกยังคงใช้กับระดับใหญ่ รหัสระดับสูงช่วยกำหนดอินเตอร์เฟสระดับต่ำ ในขณะที่ถ้าอินเตอร์เฟสระดับต่ำถูกเขียนก่อน (หรือมีอยู่แล้ว) รหัสระดับสูงจะอยู่ที่ความเมตตาของพวกเขา ...

^{1. อันนี้ใช้ได้แม้ว่าคุณจะไม่ได้ทำ full-on TDD แม้ว่าคุณจะเพิ่งเขียนการทดสอบ 1 หรือ 2 ก่อนการใช้งานการทดสอบ 1 หรือ 2 นั้นสามารถช่วยคุณกำหนดหรือปรับแต่งอินเทอร์เฟซของคุณก่อนที่จะสายเกินไป!}

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

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

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

ที่กล่าวว่า

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

เข้าใจว่าการทดสอบหน่วยไม่ใช่แค่การทดสอบที่ทำในชั้นเรียนเดียว ตราบใดที่ API ของคุณกำลังทำงานอยู่คุณสามารถทดสอบได้โดยไม่ต้องทำสิ่งใด ๆ ต่อไปนี้ที่คุณกำลังทำการทดสอบหน่วย:

• มันพูดกับฐานข้อมูล
• มันสื่อสารข้ามเครือข่าย
• มันสัมผัสระบบไฟล์
• ไม่สามารถทำงานพร้อมกันกับการทดสอบหน่วยอื่น ๆ ของคุณ
• คุณต้องทำสิ่งพิเศษกับสภาพแวดล้อมของคุณ (เช่นการแก้ไขไฟล์กำหนดค่า) เพื่อเรียกใช้

Michael Feathers: ชุดกฎการทดสอบหน่วย

ดังนั้นหากการทดสอบแบบ end-to-end ของคุณเกี่ยวข้องกับวัตถุมากกว่าหนึ่งรายการ นี่คือการทดสอบหน่วยไม่ใช่การทดสอบวัตถุ

เช่นเดียวกับวิธีการส่วนตัวไม่จำเป็นต้องทำการทดสอบอีกต่อไปจากนั้นพวกเขาจะได้รับการทดสอบผ่านการทดสอบวิธีการสาธารณะที่ใช้พวกเขาวัตถุไม่จำเป็นต้องได้รับการพัฒนาเริ่มต้นภายใต้สายการทดสอบของตัวเอง เฉพาะเมื่อวัตถุได้รับการพิจารณาให้ใช้งานโดยอิสระจากเรื่องราวแบบ end-to-end พวกเขาจำเป็นต้องได้รับการปฏิบัติอย่างแท้จริงเนื่องจากมีส่วนต่อประสานและพฤติกรรมของตัวเองเพื่อยืนยัน หากคุณระมัดระวังเกี่ยวกับสิ่งนี้คือเมื่อคุณทำให้วัตถุเหล่านั้นเป็นสาธารณะ วิธีนี้คุณจะไม่ทำสัญญาที่คุณยังไม่ได้ทดสอบ