Làm thế nào để test code tương tác với database?

Question

Accepted Answer

Test code dùng **database** là thách thức — bạn cần hành vi dữ liệu thực tế mà không flaky hoặc chậm. Các cách tiếp cận gồm **test database**, **database in-memory**, **transaction/rollback**, và **mock tầng dữ liệu** — mỗi cái có đánh đổi riêng.

## Thách thức

```text
Code tương tác database cần test, nhưng database mang lại thách thức:
  → DB thật → thực tế nhưng CHẬM HƠN; cần SETUP và CLEANUP (state giữa các test)
  → state dùng chung → test có thể can thiệp lẫn nhau (phụ thuộc thứ tự, flakiness)
  → mock DB → nhanh nhưng có thể không bắt lỗi query/integration thật
→ Chọn một cách tiếp cận cân bằng tính thực tế, tốc độ và cô lập.
```

## Các cách tiếp cận

```text
1. TEST DATABASE THẬT → một DB chuyên dụng cho test (cùng engine với production):
   ✓ thực tế (bắt vấn đề query/schema thật)  ✗ chậm hơn; cần cleanup/cô lập
   → thường chạy trong CONTAINER (Docker) cho một DB sạch, nhất quán mỗi lần chạy test
2. TRANSACTION ROLLBACK → bọc mỗi test trong một transaction, ROLL BACK sau → state sạch,
   không dữ liệu sót, nhanh hơn tạo lại dữ liệu (một pattern phổ biến)
3. DATABASE IN-MEMORY (vd SQLite in-memory) → nhanh, setup dễ  ✗ có thể khác với
   DB production (SQL/tính năng khác → có thể bỏ sót vấn đề riêng của prod)
4. MOCK tầng dữ liệu → unit test nhanh, cô lập  ✗ không test hành vi DB thật
   (dùng cho unit test; dùng DB thật cho integration test)
```

## Best practice

```text
✓ CÔ LẬP test — mỗi cái bắt đầu từ một state sạch đã biết (transaction, truncate, DB mới)
✓ Dùng DỮ LIỆU test thực tế (fixture/factory/seed)
✓ Test hành vi DB thật cho TẦNG DỮ LIỆU (integration); mock DB khi unit-test
  business logic phía trên nó
✓ Giữ test DB nhanh hợp lý; chạy một DB sạch trong CI (container)
```

## Tại sao điều này quan trọng

Hiểu cách test code tương tác database có giá trị vì **hầu hết ứng dụng dùng database**, và test truy cập dữ liệu đúng cách là quan trọng nhưng thách thức, nên đây là kiến thức thực hành hữu ích.

Code database (query, truy cập dữ liệu, persistence) cần test, nhưng database mang lại thách thức thực — chúng chậm hơn, đòi hỏi setup và cleanup, có state dùng chung có thể gây can thiệp test và flakiness, và mock chúng có thể bỏ sót lỗi query thật.

Hiểu **các cách tiếp cận và đánh đổi của chúng** là kiến thức then chốt: một **test database thật** (thực tế, bắt vấn đề query và schema thực, thường chạy trong container để nhất quán, nhưng chậm hơn và cần cô lập), **transaction rollback** (bọc mỗi test trong một transaction và roll back để có state sạch — một pattern phổ biến, hiệu quả giữ test cô lập và nhanh hợp lý), **database in-memory** (nhanh và dễ nhưng có thể khác production, rủi ro bỏ sót vấn đề riêng của prod), và **mock tầng dữ liệu** (unit test cô lập nhanh nhưng không test hành vi database thật).

Hiểu khi nào dùng mỗi cái — một database thật cho integration test tầng dữ liệu (để bắt lỗi query/schema thật), mock cho unit-test business logic phía trên tầng dữ liệu — phản ánh phán đoán đúng đắn về cân bằng tính thực tế, tốc độ và cô lập.

Hiểu **các best practice** — **cô lập test** (mỗi cái bắt đầu từ một state sạch đã biết qua transaction, truncation, hoặc một database mới, để tránh can thiệp và flakiness), dùng dữ liệu test thực tế (fixture/factory), test hành vi database thật cho tầng dữ liệu, và chạy database sạch trong CI — phản ánh database testing hiệu quả.

Vì hầu hết ứng dụng dùng database và test truy cập dữ liệu đúng cách (bắt lỗi query trong khi giữ test cô lập, nhanh và tin cậy) là quan trọng nhưng thách thức, và vì hiểu các cách tiếp cận (DB thật, transaction, in-memory, mock), đánh đổi của chúng, và best practice (cô lập, dữ liệu thực tế) cho phép database testing hiệu quả, hiểu cách test code tương tác database là kiến thức có giá trị, liên quan thực tiễn — quan trọng cho nhu cầu phổ biến là test truy cập dữ liệu tin cậy, cân bằng tính thực tế với tốc độ và cô lập, một kỹ năng hữu ích để test các ứng dụng dựa trên dữ liệu vốn là chuẩn mực.