TDD ทำงานได้ในโครงการโอเพ่นซอร์สที่ทำงานร่วมกันหรือไม่


11

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

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

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


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

@gnat ฉันได้ค้นหา StackExchange และมีคำถามสองสามข้อที่ผู้คนถามตัวอย่างของโครงการโอเพ่นซอร์สที่มีการทดสอบหน่วยซึ่งไม่เหมือนกับคำถามของฉัน ตามคำขอของคุณฉันได้เพิ่มข้อมูลเพิ่มเติม
DormoTheNord

1
DormoTheNord ฉันเชื่อว่า @gnat มีความหมายเฉพาะเจาะจงอ้างถึงตัวอย่าง
haneefmubarak

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

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

คำตอบ:


29

คุณไม่สามารถบังคับใช้แนวทาง TDD (ทดสอบก่อน) ในโครงการโอเพนซอร์สซึ่งประชาชนทั่วไปสามารถส่งแพตช์ได้

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

นี้ไม่ได้ตรวจสอบให้แน่ใจว่าการทดสอบเป็นลายลักษณ์อักษรครั้งแรกแต่ก็ไม่แน่ใจว่าการทดสอบจะเขียน


1
แน่นอนเจ้าของพื้นที่เก็บข้อมูลสามารถปฏิเสธที่จะดึงการเปลี่ยนแปลงใด ๆ ที่ไม่เป็นไปตามมาตรฐานคุณภาพของโครงการ? บางทีคุณภาพและปริมาณของการบริจาคอาจประสบหากผู้มีส่วนร่วมไม่ชอบสิ่งนี้ แต่ไม่ต้องบอกว่าคุณไม่สามารถบังคับได้ แน่นอน?
Tom W

2
@TomW: คุณจะตรวจสอบได้อย่างไรว่าข้อเสนอของฉันถูกสร้างขึ้นตามแนวทางปฏิบัติของ TDD ไม่ใช่เช่นกับการทดสอบที่เขียนขึ้นหลังจากการใช้งานเสร็จสิ้นแล้ว
Bart van Ingen Schenau

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

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

1

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

ในทางปฏิบัติสิ่งนี้อาจฆ่าความกระตือรือร้นที่ผู้คนมีส่วนร่วมในโครงการหรืออาจก่อให้เกิดไฟไหม้ในผู้ที่เห็นด้วยกับวิธีการของคุณ

ผู้วิจารณ์จะต้องเก่งเกี่ยวกับการหันมาทบทวนการออกแบบอย่างรวดเร็วอย่างไรก็ตามเพื่อไม่ให้เกิดการพัฒนา

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.