ควรตรวจสอบข้อมูลการทดสอบในการควบคุมเวอร์ชันหรือไม่?

40

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

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

testing version-control data

— Swiftheart
แหล่งที่มา

2

มีความเป็นไปได้ที่ซ้ำกันของการทดสอบหน่วยควรเก็บไว้ในที่เก็บหรือไม่?

— CVn

19

@ MichaelKjörling:Tests != Test Data

— Robert Harvey

4

@RobertHarvey True แต่ถ้าต้องการข้อมูลการทดสอบสำหรับการทดสอบการทำงานฉันรู้สึกว่ามันควรได้รับการพิจารณาเป็นส่วนหนึ่งของการทดสอบ นั่นเป็นวิธีการที่ตอบโดยทั้งสามคำตอบเท่าที่ฉันเข้าใจ

— CVn

84

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

ฉันควรจะสามารถตรวจสอบโครงการและมีสภาพแวดล้อมในการรวบรวมสร้างและทดสอบอย่างสมบูรณ์

มีสองวิธีในการตรวจสอบข้อมูลการทดสอบ ก่อนอื่นคุณสามารถตรวจสอบข้อมูลการทดสอบได้เอง (PDF ในกรณีนี้) ประการที่สองคุณสามารถตรวจสอบแหล่งข้อมูลที่สามารถใช้ในการสร้างข้อมูลทดสอบ (ถ้ามี) นี่อาจเป็นสคริปต์ SQL ที่โหลดลงในฐานข้อมูลเปล่าที่มีข้อมูลทดสอบหรืออาจเป็นไฟล์ข้อความที่สามารถคอมไพล์เป็นไฟล์ PDF หรือไฟล์อื่น ๆ

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

20

ใช่. ใช่แน่นอน มันเป็นปี 2014 ไม่มีเหตุผลใด ๆ สำหรับการใช้การควบคุมการแก้ไขที่ไม่ได้จัดการกับไฟล์ไบนารีอย่างราบรื่น

— Kilian Foth

4

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

— Kenneth Garza

1

@KennethGarza มันไม่ยากจริงๆ ตามกฎทั่วไปเนื้อหาต้นฉบับใด ๆ (ซอร์สโค้ดทดสอบซอร์สข้อมูลการทดสอบสื่อเอกสาร [ของจริง] ห้องสมุดบุคคลที่สามสร้างสคริปต์สคริปต์เครื่องมือสคริปต์แปลงสคริปต์ ฯลฯ ) ควรรวมอยู่ในขณะที่ข้อมูลทั้งหมด ที่สามารถสร้างขึ้นในเวลาที่เหมาะสมจากข้อมูลต้นฉบับไม่ควร นอกจากนี้ยังให้ผู้ที่มีผลการทดสอบพวกเขาอาจเพียง แต่จะทำให้ความรู้สึกหลังจากใช้การทดสอบด้วยตัวเองมิฉะนั้นคุณจะไม่ได้รับการทดสอบโปรแกรมของคุณคุณกำลังทดสอบความสามารถของซอฟต์แวร์ VCS ที่จะรักษาความสมบูรณ์ของไฟล์ของคุณ :)

— โทมัส

1

@ MarnenLaibow-Koser: โครงการที่ฉันทำงานเพื่อตรวจสอบความล้มเหลวของไฟฟ้าในเครื่องกระตุ้นหัวใจที่ฝังอยู่นั้นมีชุดทดสอบมากกว่า 40GB ไม่มี VCS ในการดำรงอยู่ที่จัดการกับสิ่งนั้นไม่น่ารังเกียจ การมีสอง repos เป็นความยุ่งยากในการจัดการของตัวเอง แต่บางครั้งมันอาจเป็นทางเลือกที่ดีกว่า

— whatsisname

1

@ MarnenLaibow-Koser คุณได้รับมัน การทดสอบการรวมอยู่ใน repo แยกต่างหากและหากผู้ใช้ต้องการเรียกใช้งานแบบโลคัลการจัดการการพึ่งพาจะดึงไฟล์ zip สำหรับเขาและคลายการบีบอัด โดยปกติเซิร์ฟเวอร์การรวมต่อเนื่อง / ฟาร์มจะได้รับมอบหมายให้ทำการทดสอบการรวมและจะป้องกันการรวมสาขาคุณลักษณะจนกว่าการทดสอบการรวมจะผ่าน

— user482745

15

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

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

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

ฉันจะพิจารณาใส่ความคิดเห็นในรหัสทดสอบที่ระบุว่า "ต้องอาศัยfoo.pdfเพื่อดำเนินการทดสอบทั้งหมด"

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

— Warbo

7

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

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

— Warbo
แหล่งที่มา

2

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

— Dawood กล่าวว่าคืนสถานะโมนิก้า

5

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

— Warbo

5

@DavidWallace สุ่ม! = unreproducible

— congusbongus

5

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

— congusbongus

2

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

— Warbo

0

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

ด้วย git คุณสามารถตั้งค่า. gitignore เพื่อป้องกันเอาท์พุทชั่วคราวหรือการบันทึกการทดสอบจากการสร้างมลพิษ repo ของคุณ

— NickJHoran
แหล่งที่มา