ป้ายกำกับ: หน่วยเป็นวินาที

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

Clean Architecture คือแนวคิดที่ช่วยแยกส่วนประกอบของโค้ดออกจากกันอย่างชัดเจน เพื่อให้แต่ละส่วนสามารถทดสอบได้อย่างอิสระ ในบริบทของ PostgreSQL ซึ่งเป็นระบบจัดการฐานข้อมูล (DBMS) การจำลองสภาพแวดล้อม (Mocking) และการสร้างข้อมูลจำลอง (Stubbing) จึงมีความสำคัญอย่างยิ่ง เพื่อให้เราสามารถทดสอบ Logic ทางธุรกิจ (Business Logic) โดยไม่จำเป็นต้องพึ่งพาข้อมูลจริงหรือระบบภายนอกที่พร้อมใช้งานเสมอไป

💡 Mocking และ Stubbing ในบริบทของ PostgreSQL

Mocking คือการสร้างวัตถุจำลองเพื่อแทนที่พฤติกรรมของ Dependency ส่วน Stubbing คือการเตรียมข้อมูลจำลอง (Stub Data) ที่มีโครงสร้างและค่าที่คาดเดาได้ เพื่อให้ฟังก์ชันหรือ Query ของเราทำงานภายใต้สถานการณ์ที่ควบคุมได้

สำหรับ PostgreSQL เราสามารถใช้คุณสมบัติของ Common Table Expressions (CTEs) หรือ Temporary Tables เพื่อทำหน้าที่เป็น Mocking Layer โดยการสร้างชุดข้อมูลจำลองที่สมบูรณ์แบบสำหรับชุดคำสั่ง SQL ที่เราต้องการทดสอบโดยเฉพาะ

🧪 ตัวอย่างการใช้ CTEs เพื่อ Stub Data

สมมติว่าเรามีฟังก์ชันที่ต้องคำนวณคะแนนรวมจากตาราง `orders` และ `products` แต่ในการทดสอบ เราต้องการจำลองสถานการณ์ที่ว่ามีสินค้า 3 ชิ้นเท่านั้น โดยไม่จำเป็นต้องมีข้อมูลจริงในตาราง `products` เลย เราสามารถใช้ CTE เพื่อ Stub ข้อมูลสินค้าได้ดังนี้:

SQL

-- 1. สร้างข้อมูลจำลอง (Stub) สำหรับตาราง products โดยใช้ CTEs (WITH) </code>
WITH stub_products AS (
    SELECT 1 AS product_id, 'apple' AS name, 10.00 AS price
    UNION ALL
    SELECT 2, 'banana', 5.50
    UNION ALL
    SELECT 3, 'orange', 7.00
)
SELECT
    o.order_id,
    p.name,
    o.quantity * p.price AS total_cost
FROM
    (SELECT 100 AS order_id, 2 AS product_id, 3 AS quantity) AS o
JOIN
    stub_products p ON o.product_id = p.product_id;

ในตัวอย่างนี้ stub_products ทำหน้าที่เป็น Mocking Layer ที่จำลองตารางสินค้า ทำให้เราสามารถทดสอบการ JOIN และการคำนวณได้โดยที่ระบบไม่จำเป็นต้องพึ่งพาข้อมูลจริงของตาราง products เลยแม้แต่น้อย

✨ ข้อดีของการ Mocking ใน PostgreSQL

• Isolation: การทดสอบ Logic ทางธุรกิจจะแยกออกจากความผันผวนของข้อมูลจริง ทำให้ผลลัพธ์ที่ได้มีความน่าเชื่อถือสูง
• Speed: การรัน Test Case ที่ใช้ข้อมูลจำลองจะรวดเร็วกว่าการรัน Test Case ที่ต้องดึงข้อมูลจากระบบจริง
• Reliability: รับประกันได้ว่า Test Case จะล้มเหลวเฉพาะเมื่อ Logic ของเราผิดพลาดเท่านั้น ไม่ใช่เพราะข้อมูลในฐานข้อมูลจริงมีการเปลี่ยนแปลง

✅ บทสรุป

การนำหลักการ Mocking และ Stubbing มาประยุกต์ใช้กับ PostgreSQL ผ่าน CTEs หรือ Temporary Tables ไม่เพียงแต่ช่วยให้การทดสอบของเรามีความสมบูรณ์แบบเท่านั้น แต่ยังช่วยให้สถาปัตยกรรมระบบของเรามีความยืดหยุ่นและสามารถบำรุงรักษาได้ง่ายขึ้น ทำให้เรามั่นใจได้ว่า Business Logic ที่สำคัญของเราจะทำงานได้อย่างถูกต้องในทุกสถานการณ์ ไม่ว่าข้อมูลจริงจะอยู่ในสภาพใดก็ตาม