คุณจะทดสอบหน่วย \ ใช้วิธี TDD สำหรับโครงการ ETL และการรายงานได้อย่างไร


12

โครงการ ETL เป็นโครงการที่สร้างขึ้นโดยใช้เครื่องมือ ETL (ดึงข้อมูล - แปลง - โหลด) เช่น SSIS, PowerCenter เป็นต้น

โดยทั่วไปจะเกี่ยวข้องกับการอ่านข้อมูลจากแหล่งภายนอกโหลดไปยังฐานข้อมูลการแสดงการแปลงและโหลดไปยังฐานข้อมูลสุดท้าย

ตัวอย่างง่ายๆคือการใช้ SSIS เพื่ออ่านไฟล์ excel ที่เตรียมไว้โดยครูผู้สอนโดยใช้ SSIS และโหลดลงในฐานข้อมูล จากนั้นเขียนกระบวนงานที่เก็บไว้หรือแพ็คเกจ SSIS เพิ่มเติมเพื่อคำนวณคะแนนของนักเรียนแต่ละคนและโหลดข้อมูลนั้นลงใน data mart \ warehouse

จากนั้นคุณสร้างกระบวนงานที่เก็บไว้ด้านบนของตลาดเพื่อสร้างผลลัพธ์ที่ใช้โดยเครื่องมือการรายงาน (SSRS \ Excel \ etc) เพื่อสร้างการแสดงภาพประกอบเพลง

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

ตัวอย่าง:

Sprint 1: ตารางนักเรียนประกอบด้วยชื่อ, อายุ, เกรด

คุณสร้างข้อมูลทดสอบสำหรับตารางนี้และทดสอบหน่วยตามนั้น

Sprint 2: เขตข้อมูลเพศถูกเพิ่มลงในตาราง

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


ไม่ใช่ TDD หากเครื่องมือที่คุณทดสอบมีอยู่แล้ว แค่เขียนข้อสอบธรรมดา
Robert Harvey

@RobertHarvey เครื่องมือ ETL ไม่แตกต่างจาก. Net Framework เมื่อเขียนรหัส C # ใช่หรือไม่? ดังนั้นเครื่องมือมีอยู่ในลักษณะเดียวกันกับ. Net framework แต่คุณสามารถทำ TDD ใน C # ได้
user87166

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

1
จากนั้นเขียนการทดสอบโดยใช้ความคาดหวังที่คุณคาดหวังว่าจะได้รับจาก ETL ข้อมูลที่เสนอและการกำหนดค่าที่เสนอ ทำให้พวกเขาทดสอบแนวคิดถ้าคุณชอบ แต่การทำงานอยู่แล้ว การพัฒนา "การทดสอบครั้งแรก" บริสุทธิ์สำหรับสิ่งที่ยังไม่มี ไม่ว่าคุณจะทำอะไรอย่าสร้างเครื่องมือ ETL ขึ้นมาใหม่!
Robert Harvey

2
"ตั้งแต่อายุในฐานข้อมูลเปลี่ยนไป" - อะไรคือสิ่งที่ยากมากเกี่ยวกับการให้ข้อมูลการทดสอบที่มั่นคงในฐานะอินพุต? หากมีการคำนวณขึ้นอยู่กับเวลาให้จำลองการจับเวลาอ้างอิง
Doc Brown

คำตอบ:


2

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

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

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


0

ETL สามารถทำได้ด้วย TDD และทดสอบในลักษณะที่คล้ายคลึงกับโครงการส่วนใหญ่เช่น

เขียนการทดสอบที่ล้มเหลว (สีแดง) แก้ไขความล้มเหลว (สีเขียว) ทำให้โค้ดปรุและรักษาได้ (refactor)

ดังนั้นสำหรับ ETL ที่อาจเป็น:

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

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