การทดสอบหน่วยของขั้นตอนการจัดเก็บ


44

ฉันได้พิจารณาเรื่องนี้มานานแล้ว

คำถามพื้นฐานคือ: วิธีการทดสอบหน่วยจัดเก็บขั้นตอน?

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

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

ดังนั้นคุณจะทดสอบวิธีการจัดเก็บของคุณได้อย่างไร มีปัญหาความยุ่งยากซับซ้อนหรือไม่เมื่อมีการสิ้นหวัง ทรัพยากรใดที่จำเป็นสำหรับการบำรุงรักษา

แก้ไขคำถามเล็ก ๆ อีกข้อหนึ่งตามคำตอบของ AlexKuznetsov: หรือมีโครงเรื่องที่ไม่มีประโยชน์อย่างสมบูรณ์หรือไม่

คำตอบ:


32

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

ฉันเขียนบทความเรื่องปิดช่องโหว่เหล่านั้น: บทเรียนที่ได้จากการทดสอบหน่วย T-SQLรวมถึงบางบทความในบล็อก

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

เพื่อให้การบำรุงรักษาง่ายขึ้นเราสร้างผลลัพธ์ที่คาดหวังและเราเก็บไว้ในไฟล์แยกต่างหาก - ซึ่งสร้างความแตกต่างอย่างมาก


15

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

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

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

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

  1. คุณมักจะเขียนรหัสปราศจากข้อบกพร่องหรือไม่?
  2. หน่วยเล็ก ๆ มีข้อบกพร่องอยู่เสมอหรือไม่?
  3. เป็นเรื่องปกติไหมที่ยูนิตขนาดใหญ่จะมีปัญหา?
  4. มีข้อบกพร่องกี่ข้อในการทำให้เกิดภัยพิบัติ

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

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

1
ประการแรกขอขอบคุณสำหรับคำตอบของคุณ - ฉันไม่ได้คาดหวังความก้าวหน้าใด ๆ เพิ่มเติมเกี่ยวกับคำถามนี้ ... ประการที่สองฉันต้องยอมรับว่าคุณถูกต้องเกี่ยวกับการดำเนินการอย่างง่าย: แม้แต่ INSERT สองคอลัมน์ก็สามารถสร้างบั๊กได้ หากมีการเขียนเพื่อให้ลำดับคอลัมน์สามารถจับคู่กับข้อโต้แย้งก็อาจจะตกลง แต่คุณก็ถูกต้องอีกครั้ง: มันน่าจะทำให้แอปทั้งหมดภายใต้ระบอบการทดสอบ
dezso

@dezso มันเป็นคำถามที่ยอดเยี่ยมและมีคอนเซปต์ที่ต้องการการเปิดรับมากขึ้นในโลกของฐานข้อมูล
Leigh Riffel

"คุณควรทดสอบเหตุการณ์ทั้งหมดเป็นหน่วย" - นี่คือสิ่งที่ต่อต้านได้ง่ายที่สุดที่คุณสามารถพูดได้ มันไม่ใช่หน่วยถ้าเป็นอย่างนั้น คุณกำลังทำการทดสอบการรวม
Joe Phillips

@Joe Philips - เรียกมันว่าสิ่งที่คุณต้องการตรวจสอบให้แน่ใจว่าขั้นตอนการแทรกและยิงทริกเกอร์ไม่กี่ทำสิ่งที่มันควรจะต้องมีการทดสอบอัตโนมัติ
Leigh Riffel

8

สำหรับ PostgreSQL ตรวจสอบpgTAP :

pgTAP เป็นชุดของฟังก์ชั่นฐานข้อมูลที่ทำให้ง่ายต่อการเขียนการทดสอบหน่วย TAP เปล่งในสคริปต์ psql หรือฟังก์ชั่นการทดสอบสไตล์ xUnit


เห็นแล้วว่าขอบคุณ มีใครมีประสบการณ์กับมันหรือไม่?
dezso

ทุกวันนี้มีคนค่อนข้างน้อย สมัครสมาชิกรายการจดหมายหากคุณมีคำถาม
ทฤษฎี

6

หากคุณต้องการทดสอบขั้นตอนการจัดเก็บของคุณทั้งหมดใน SQL ให้ดูที่http://tsqlt.org/

มันเข้ากันได้กับ MS SQL 2005 SP2 และสูงกว่าและข้อดีคือนักพัฒนาไม่จำเป็นต้องรู้ภาษา C # หรือภาษาอื่นเพื่อทำการทดสอบ

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

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