Test-Driven Development (TDD) là gì?

Question

Accepted Answer

**Test-Driven Development (TDD)** là một thực hành mà bạn viết **test trước code** — theo một chu trình ngắn, lặp lại: viết một test fail, viết code để nó pass, rồi refactor. Nó dẫn dắt thiết kế thông qua test và đảm bảo code có thể test được và được test kỹ.

## Chu trình TDD: Red, Green, Refactor

```text
1. RED → viết một test FAIL cho hành vi bạn muốn (nó fail — code chưa tồn tại)
2. GREEN → viết code TỐI THIỂU để test PASS (vừa đủ, đừng làm dư)
3. REFACTOR → cải thiện/dọn dẹp code (và test) trong khi giữ test GREEN
→ Lặp lại chu trình ngắn này cho mỗi mảnh hành vi nhỏ.
```

```text
Viết test (RED) → viết code (GREEN) → dọn dẹp (REFACTOR) → lặp lại
```

## Luồng ví dụ

```js
// 1. RED — viết test trước (fail: add chưa tồn tại / sai)
test('add(2,3) === 5', () => expect(add(2, 3)).toBe(5));

// 2. GREEN — viết code tối thiểu để pass
function add(a, b) { return a + b; }

// 3. REFACTOR — cải thiện nếu cần (test vẫn pass); rồi viết test tiếp theo
```

## Lợi ích và lưu ý

```text
✓ Đảm bảo code TEST ĐƯỢC (bạn thiết kế để test) và ĐƯỢC TEST (test tồn tại theo định nghĩa)
✓ Dẫn dắt THIẾT KẾ — nghĩ về hành vi/interface trước → code sạch hơn, tập trung
✓ PHẢN HỒI nhanh; tự tin refactor; tránh over-engineering (chỉ viết cái cần thiết)
✓ Độ bao phủ test tốt như một kết quả tự nhiên
⚠️ Một kỷ luật/kỹ năng cần luyện tập; không phải lúc nào cũng áp dụng giáo điều (dùng phán đoán)
```

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

Hiểu Test-Driven Development có giá trị vì nó là một **thực hành có ảnh hưởng, được bàn luận rộng rãi** định hình cách nhiều lập trình viên tiếp cận testing và thiết kế, nên đây là kiến thức quan trọng cho phát triển chuyên nghiệp.

Ý tưởng cốt lõi của TDD — **viết test trước code**, theo **chu trình Red-Green-Refactor** (viết một test fail, viết code tối thiểu để pass, rồi refactor trong khi giữ test green) — là một cách tiếp cận đặc biệt đảo ngược thứ tự thông thường.

Hiểu chu trình là kiến thức thực hành then chốt.

Hiểu **lợi ích** giải thích tại sao TDD được coi trọng: nó đảm bảo code **test được** (bằng cách thiết kế để test ngay từ đầu) và **được test** (test tồn tại theo định nghĩa), **dẫn dắt thiết kế** (nghĩ về hành vi và interface trước dẫn đến code sạch hơn, tập trung hơn), cung cấp phản hồi nhanh và sự tự tin để refactor, tránh over-engineering (chỉ viết cái cần để pass test), và tự nhiên tạo ra độ bao phủ test tốt.

Những lợi ích này làm cho TDD có ảnh hưởng như một thực hành cả về testing và thiết kế.

Hiểu **các lưu ý** — rằng TDD là một kỷ luật đòi hỏi luyện tập, và rằng nó không phải lúc nào cũng được áp dụng giáo điều (lập trình viên dùng phán đoán về khi nào nó phù hợp) — phản ánh một quan điểm cân bằng, thực tế.

Ngay cả lập trình viên không luôn thực hành TDD cũng hưởng lợi từ việc hiểu nó, vì nó định hình tư duy về testing và thiết kế và là một chủ đề phổ biến trong phát triển chuyên nghiệp và phỏng vấn.

Vì TDD là một thực hành có ảnh hưởng, được biết đến rộng rãi định hình cách tiếp cận testing và thiết kế (với lợi ích thực sự về khả năng test, thiết kế và độ bao phủ) và là một chủ đề phỏng vấn và chuyên nghiệp phổ biến, và vì hiểu chu trình, lợi ích và lưu ý phản ánh sự trưởng thành về testing, hiểu Test-Driven Development là kiến thức có giá trị, liên quan — một thực hành và triết lý testing quan trọng đáng hiểu cho phát triển chuyên nghiệp, có ảnh hưởng đến cách các lập trình viên chú trọng chất lượng tiếp cận việc xây dựng phần mềm.