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

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

สิ่งที่ฉันหายไปที่นี่?

ในสถานการณ์การพัฒนาซอฟต์แวร์โดยทั่วไปการทดสอบจะใช้สองจุด: ระหว่างการพัฒนาและก่อนการเคลื่อนย้ายผลิตภัณฑ์ตามสายการพัฒนา

สถานการณ์แรกที่เรียกใช้การทดสอบในระหว่างการพัฒนาให้บริการเป้าหมายระยะสั้น: การกำหนดงาน (เช่นเดียวกับใน TDD: เขียนการทดสอบที่ล้มเหลวจากนั้นผ่านการทดสอบ) ป้องกันการถดถอยทำให้แน่ใจได้ว่าการเปลี่ยนแปลงของคุณจะไม่ผิดเพี้ยน การทดสอบจะต้องรวดเร็วมาก: โดยปกติแล้วชุดทดสอบทั้งหมดของคุณจะทำงานในเวลาน้อยกว่า 5 วินาทีและคุณสามารถรันในลูปถัดจาก IDE หรือโปรแกรมแก้ไขข้อความในขณะที่คุณใช้โค้ด การถดถอยที่คุณแนะนำจะปรากฏขึ้นภายในไม่กี่วินาที การทดสอบที่รวดเร็วนั้นมีความสำคัญมากกว่าในช่วงนี้มากกว่าการจับ 100% ของการถดถอยและข้อบกพร่องและเนื่องจากมันเป็นไปไม่ได้ (หรือเป็นไปไม่ได้ทันที) ในการพัฒนาบนสำเนาที่แน่นอนของระบบการผลิตความพยายามในการทดสอบที่สมบูรณ์แบบ มัน. การใช้ฐานข้อมูลในหน่วยความจำเป็นการแลกเปลี่ยนที่ไม่เป็นไปตามระบบการผลิตจริง แต่จะช่วยให้การทดสอบดำเนินการต่ำกว่าขีด จำกัด 5 วินาที หากตัวเลือกอยู่ระหว่างการตั้งค่าฐานข้อมูลที่แตกต่างกันเล็กน้อยสำหรับการทดสอบที่เกี่ยวข้องกับฐานข้อมูลของฉันและไม่มีการทดสอบเลยฉันรู้ว่าฉันเลือกอะไร

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

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

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

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

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

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

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

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

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

ในฐานข้อมูลหน่วยความจำมีข้อดี:

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

ขึ้นอยู่กับระบบฐานข้อมูลที่คุณใช้ เมื่อระบบฐานข้อมูลของคุณมอบทางเลือกในหน่วยความจำให้คุณซึ่งเกือบ 100% API และพฤติกรรมที่เข้ากันได้กับการกำหนดค่าฐานข้อมูลบนดิสก์ (ยกเว้นความเร็วและ beeing ล้มเหลวไม่ปลอดภัยหรือแน่นอน) จากนั้นใช้ตัวแปรในหน่วยความจำ .

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

ในคำพูดของคนธรรมดา:

การเยาะเย้ยของส่วนที่สำคัญของสถาปัตยกรรมคือตกลง (และต้อง) สำหรับการทดสอบหน่วยการทดสอบหน่วย

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

ท้ายที่สุดแล้วการทดสอบการรวมกำลังจะทดสอบว่าส่วนต่าง ๆ ของสถาปัตยกรรมทำงานร่วมกันอย่างไร