TDD พร้อมฟังก์ชัน SQL และการปรับเปลี่ยนข้อมูล

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

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

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

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

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

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

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

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

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

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

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

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

ชุดผลลัพธ์ที่คาดหวังสามารถบันทึกในตารางฐานข้อมูลหรือไฟล์ / สเปรดชีตภายนอก ฉันเคยเห็น CHECKSUM ใช้หรือเปรียบเทียบ เมื่อคุณทดสอบมุมมอง / sproc คุณจะได้รับความล้มเหลวเนื่องจากไม่มีอยู่ จากนั้นคุณสร้างวัตถุที่มีรหัสเพียงพอที่จะดำเนินการอย่างน้อย (SELECT -1 เป็น [ไม่ถูกต้อง];) และคุณจะได้รับความล้มเหลวเนื่องจากไม่ตรงกับชุดผลลัพธ์ เมื่อตรงกับที่คุณมีไฟเขียวของคุณ

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

หากแพลตฟอร์มฐานข้อมูลของคุณ SQL Server มีเครื่องมือฟรีที่ดีมาก: tSQLt

tSQLt เป็นกรอบการทดสอบหน่วยฐานข้อมูลสำหรับ Microsoft SQL Server tSQLt เข้ากันได้กับ SQL Server 2005 (จำเป็นต้องมี Service Pack 2) และสูงกว่าในทุกรุ่น

ฉันใช้การทดสอบในระดับฐานข้อมูลเรียบร้อยแล้ว

องค์ประกอบสำคัญบางประการที่ทำให้มีประโยชน์มีดังนี้:

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