TDD สำหรับการประมวลผลแบบแบตช์: จะทำอย่างไร?


14

ฉันชอบ "สีแดง / สีเขียว / refactor" สำหรับ RoR ฯลฯ ก็โอเค

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

การเปลี่ยนแปลงคุณลักษณะของไฟล์เหล่านี้สูงดังนั้นจึงมีการแก้ไข / ปรับปรุงจำนวนมากที่ใช้บ่อย

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

Q >> จะนำหลักการของ TDD มาสู่สิ่งแวดล้อมแบบนี้ได้อย่างไร?


1
มันปั่นป่วนกับข้อมูลหรือซอร์สโค้ดหรือทั้งสองอย่าง?
rwong

คำตอบ:


5

เพียงแค่ FYI: การทดสอบหน่วยไม่เทียบเท่ากับ TDD TDD เป็นกระบวนการที่การทดสอบหน่วยเป็นองค์ประกอบ

จากที่กล่าวมาหากคุณต้องการใช้การทดสอบหน่วยแล้วมีหลายสิ่งที่คุณสามารถทำได้:

มีการทดสอบรหัส / การปรับปรุงใหม่ทั้งหมด

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

ทดสอบข้อมูลแต่ละชิ้น

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

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

นั่นควรให้ฐานที่แข็งแกร่งแก่คุณ

การใช้ข้อมูลจริง

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


3
ตรวจสอบให้แน่ใจว่าคุณเปิดเผยข้อมูลการทดสอบอย่างไม่เหมาะสมหากจำเป็น
Frank Shearar

1

มันเหมือนกับสภาพแวดล้อมอื่น ๆ

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

จากนั้นเขียนการทดสอบสำหรับแต่ละกฎ การทดสอบเหล่านี้จะล้มเหลว เขียนรหัสเพื่อแก้ไขการทดสอบ

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


1

เริ่มต้นด้วยกลยุทธ์ซอฟต์แวร์ที่ดีจากนั้นใช้ TDD

(ข้อจำกัดความรับผิดชอบ: ฉันอาจเข้าใจผิด "ปั่น" หรือ TDD หรือทั้งสองอย่าง)

นี่คือกลยุทธ์ที่แนะนำสำหรับการประมวลผลแบทช์ "ข้อมูลที่สกปรก": Specify-Triage-Execute

  • ร่างข้อกำหนดของข้อมูลอย่างเข้มงวดและแคบ แต่จะครอบคลุมข้อมูลส่วนใหญ่ (พูด 80% หรือมากกว่า) ของข้อมูลที่เข้ามา เรียกสิ่งนี้ข้อมูลจำเพาะ 1
  • พัฒนาTriageโมดูล (TDD หากคุณต้องการ) ที่ตัดสินใจว่าบันทึกตรงตามข้อกำหนด 1
    • ตรวจสอบให้แน่ใจว่าโมดูลทำงานเร็วมาก
    • โมดูลควรกลับจริง / เท็จ: มันเป็นไปตามกฎทั้งหมดหรือไม่
  • พัฒนาดำเนินการโมดูล (TDD หากคุณต้องการ) ที่แยกวิเคราะห์เรคคอร์ดที่เป็นที่รู้จักเพื่อให้ตรงตามข้อมูลจำเพาะ 1 โดยปฏิบัติงานตามที่ลูกค้าต้องการ
  • ใช้Triage 1กับข้อมูลที่เข้ามาทั้งหมด
    • ผลลัพธ์คือค่าบูลีนหนึ่งค่าสำหรับแต่ละระเบียน สิ่งนี้จะแยกข้อมูลขาเข้าออกเป็น: ข้อมูลจำเพาะ 1 หรือไม่รู้จัก
    • ใช้Execute 1กับข้อมูลจำเพาะ 1 เมื่อใดก็ตามที่ลูกค้าต้องการ
  • ผ่อนคลายกฎของข้อกำหนด 1 เพื่อยอมรับ 80% ของข้อมูลที่เหลือ เรียกสิ่งนี้ข้อมูลจำเพาะ 2
  • พัฒนาTriage 2และดำเนินการ 2 นำไปใช้กับข้อมูลใด ๆ ที่ไม่ตรงตามข้อกำหนด 1
  • ทำซ้ำในหลาย ๆ ระดับตามที่ต้องการจนกว่าข้อมูลที่เหลือจะมีขนาดเล็กพอที่จะประมวลผลด้วยตนเองทุกวัน

ชิ้นอาหารอันโอชะที่มีประสิทธิภาพ:

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

"คุณต้องรู้ว่าคุณต้องการสร้างอะไรก่อนที่จะทำ TDD" ชิ้นอาหารอันโอชะ:

Specify-Triage-Execute เป็นวิธีหนึ่งในการจัดการความต้องการในแต่ละระดับและช่วยให้การเติบโตในอนาคต

(หากมีใครรู้คำที่ถูกต้องมาตรฐานสำหรับสามขั้นตอนเหล่านั้นโปรดแจ้งให้เราทราบฉันจะแก้ไขคำตอบของฉัน)

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