คุณทดสอบโค้ดที่โต้ตอบกับฐานข้อมูลอย่างไร?

Question

Accepted Answer

การทดสอบโค้ดที่ใช้ **ฐานข้อมูล** เป็นเรื่องท้าทาย — คุณต้องการพฤติกรรมข้อมูลที่สมจริงโดยไม่มี flakiness หรือความช้า แนวทางต่าง ๆ ได้แก่ **test database**, **in-memory database**, **transaction/rollback**, และ **การ mock ชั้นข้อมูล** — แต่ละแบบมี trade-off

## ความท้าทาย

```text
Database-interacting code needs testing, but databases bring challenges:
  → real DB → realistic but SLOWER; needs SETUP and CLEANUP (state between tests)
  → shared state → tests can interfere (order dependence, flakiness)
  → mocking the DB → fast but may not catch real query/integration bugs
→ Choose an approach balancing realism, speed, and isolation.
```

## แนวทาง

```text
1. REAL TEST DATABASE → a dedicated DB for tests (same engine as production):
   ✓ realistic (catches real query/schema issues)  ✗ slower; needs cleanup/isolation
   → often run in a CONTAINER (Docker) for a clean, consistent DB per test run
2. TRANSACTION ROLLBACK → wrap each test in a transaction, ROLL BACK after → clean state,
   no leftover data, faster than recreating data (a common pattern)
3. IN-MEMORY DATABASE (e.g. SQLite in memory) → fast, easy setup  ✗ may differ from the
   production DB (different SQL/features → can miss prod-specific issues)
4. MOCK the data layer → fast, isolated UNIT tests  ✗ doesn't test real DB behavior
   (use for unit tests; use a real DB for integration tests)
```

## แนวทางปฏิบัติที่ดี

```text
✓ ISOLATE tests — each starts from a known clean state (transactions, truncate, fresh DB)
✓ Use realistic test DATA (fixtures/factories/seeds)
✓ Test real DB behavior for the DATA LAYER (integration); mock the DB when unit-testing
  business logic above it
✓ Keep DB tests reasonably fast; run a clean DB in CI (containers)
```

## ทำไมจึงสำคัญ

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

โค้ดฐานข้อมูล (query การเข้าถึงข้อมูล การ persist) ต้องได้รับการทดสอบ แต่ฐานข้อมูลนำมาซึ่งความท้าทายจริง — มันช้ากว่า ต้องการ setup และ cleanup มี shared state ที่อาจทำให้เทสต์รบกวนกันและเกิด flakiness และการ mock มันอาจพลาดบั๊กของ query จริง

การเข้าใจ **แนวทางและ trade-off ของแต่ละแบบ** คือความรู้สำคัญ: **test database จริง** (สมจริง จับปัญหา query และ schema จริง มักรันใน container เพื่อความสม่ำเสมอ แต่ช้ากว่าและต้องการ isolation) **transaction rollback** (ห่อแต่ละเทสต์ใน transaction แล้ว roll back เพื่อ state ที่สะอาด — รูปแบบที่พบบ่อยและมีประสิทธิภาพซึ่งรักษาเทสต์ให้แยกอิสระและเร็วพอสมควร) **in-memory database** (เร็วและง่ายแต่อาจต่างจาก production เสี่ยงต่อการพลาดปัญหาเฉพาะ prod) และ **การ mock ชั้นข้อมูล** (unit test ที่เร็วและแยกอิสระแต่ไม่ได้ทดสอบพฤติกรรมฐานข้อมูลจริง)

การเข้าใจว่าเมื่อใดควรใช้แต่ละแบบ — ฐานข้อมูลจริงสำหรับ integration testing ชั้นข้อมูล (เพื่อจับบั๊ก query/schema จริง) การ mock สำหรับ unit-testing business logic เหนือชั้นข้อมูล — สะท้อนการตัดสินใจที่ดีเกี่ยวกับการสมดุลความสมจริง ความเร็ว และ isolation

การเข้าใจ **แนวทางปฏิบัติที่ดี** — **การแยกเทสต์ให้อิสระ** (แต่ละเทสต์เริ่มจาก state ที่สะอาดและรู้จักผ่าน transaction การ truncate หรือฐานข้อมูลใหม่ เพื่อหลีกเลี่ยงการรบกวนและ flakiness) การใช้ข้อมูลทดสอบที่สมจริง (fixtures/factories) การทดสอบพฤติกรรมฐานข้อมูลจริงสำหรับชั้นข้อมูล และการรันฐานข้อมูลที่สะอาดใน CI — สะท้อนการทดสอบฐานข้อมูลที่มีประสิทธิภาพ

เนื่องจากแอปพลิเคชันส่วนใหญ่ใช้ฐานข้อมูลและการทดสอบการเข้าถึงข้อมูลอย่างถูกต้อง (จับบั๊ก query ในขณะที่รักษาเทสต์ให้แยกอิสระ เร็ว และเชื่อถือได้) นั้นสำคัญแต่ท้าทาย และเนื่องจากการเข้าใจแนวทาง (DB จริง transaction in-memory mock) trade-off และแนวทางปฏิบัติที่ดี (isolation ข้อมูลสมจริง) ช่วยให้ทดสอบฐานข้อมูลได้อย่างมีประสิทธิภาพ การเข้าใจวิธีทดสอบโค้ดที่โต้ตอบกับฐานข้อมูลจึงเป็นความรู้ที่มีคุณค่าและเกี่ยวข้องในทางปฏิบัติ — สำคัญต่อความจำเป็นทั่วไปในการทดสอบการเข้าถึงข้อมูลอย่างเชื่อถือได้ การสมดุลความสมจริงกับความเร็วและ isolation ทักษะที่มีประโยชน์ในการทดสอบแอปพลิเคชันที่ขับเคลื่อนด้วยข้อมูลซึ่งเป็นบรรทัดฐาน