TDD vs SDD: Khác nhau thế nào và nên dùng gì trong dự án thực tế?

Bài viết học nhanh cho team product và engineering: hiểu đúng bản chất, thấy rõ ưu nhược điểm, và biết cách kết hợp để ra sản phẩm đúng yêu cầu, ít lỗi.

1) Tóm tắt siêu nhanh (đọc 60 giây)

• TDD (Test-Driven Development): viết test trước, viết code sau để test pass.
• SDD (Spec-Driven Development): viết đặc tả trước (spec), rồi triển khai theo spec.

Nếu nói ngắn gọn:

• TDD giúp bạn “xây đúng kỹ thuật”.
• SDD giúp bạn “xây đúng thứ cần xây”.

Trong phần lớn dự án thực tế, cách hiệu quả nhất là: SDD ở mức feature + TDD ở mức implementation.

2) Định nghĩa rõ ràng

TDD là gì?

TDD là vòng lặp phát triển Red -> Green -> Refactor:

1. Red: Viết test mới và để nó fail.
2. Green: Viết lượng code nhỏ nhất để test pass.
3. Refactor: Tối ưu thiết kế code, test vẫn phải pass.

Mục tiêu chính: chất lượng kỹ thuật ổn định, giảm regression, tăng khả năng refactor an toàn.

SDD là gì?

SDD là cách phát triển dựa trên đặc tả (specification) đã thống nhất:

1. Xác định mục tiêu, phạm vi, rule, acceptance criteria.
2. Thiết kế và triển khai bám theo spec.
3. Kiểm chứng kết quả có khớp spec không.

Mục tiêu chính: đồng bộ giữa business và engineering, hạn chế làm sai nhu cầu.

Lưu ý: nhiều đội có thể gọi gần nghĩa bằng BDD/ATDD ở một số ngữ cảnh. Cốt lõi vẫn là “spec dẫn đường”.

3) So sánh tổng quan

4) Sơ đồ tư duy nhanh

flowchart LR
    A[Ý tưởng tính năng] --> B{Bắt đầu từ đâu?}
    B -->|Spec trước| C[SDD]
    B -->|Test trước| D[TDD]

    C --> E[Define rules + AC]
    E --> F[Implement theo spec]
    F --> G[Validate đúng nhu cầu]

    D --> H[Red: test fail]
    H --> I[Green: code pass test]
    I --> J[Refactor an toàn]

    G --> K[Đúng cái cần làm]
    J --> L[Làm đúng cách]

    K --> M[Kết hợp để tối ưu]
    L --> M

5) Ưu điểm chi tiết

Ưu điểm của TDD

Ưu điểm của SDD

6) Nhược điểm chi tiết

Nhược điểm của TDD

Nhược điểm của SDD

7) Ví dụ dễ hình dung: tính năng chuyển tiền

Nếu đi theo SDD trước

Bạn sẽ chốt:

• Rule: hạn mức ngày, điều kiện OTP, phí theo bậc.
• Luồng lỗi: OTP sai 3 lần, timeout khi gọi đối tác, rollback trạng thái giao dịch.
• Acceptance criteria: từng tình huống người dùng thấy gì.

Sau đó dùng TDD cho phần rủi ro cao

Bạn viết test trước cho:

• Tính phí theo từng tier.
• Chặn giao dịch vượt hạn mức.
• Retry đúng khi timeout có thể phục hồi.
• Không trừ tiền 2 lần khi callback trễ.

Kết quả:

• SDD đảm bảo đúng nghiệp vụ.
• TDD đảm bảo code bền và ít lỗi hồi quy.

8) Khi nào nên chọn gì?

9) Công thức kết hợp thực dụng (khuyên dùng)

1. Spec nhẹ 1 trang/feature: mục tiêu, phạm vi, rule, AC.
2. Đánh dấu vùng rủi ro cao: tiền, trạng thái, phân quyền, tích hợp ngoài.
3. Áp dụng TDD bắt buộc cho vùng rủi ro cao.
4. Dùng integration/e2e cho các luồng chính và lỗi trọng yếu.
5. Review theo 2 câu hỏi:
   • Có đúng spec chưa?
   • Có đủ test ngăn regression chưa?

flowchart TD
    A[Feature request] --> B[Viết mini-spec]
    B --> C{Có rule rủi ro cao?}
    C -->|Có| D[TDD bắt buộc]
    C -->|Không| E[Test mức phù hợp]
    D --> F[Integration/E2E then chốt]
    E --> F
    F --> G{Pass AC + Pass tests?}
    G -->|Yes| H[Ready to release]
    G -->|No| I[Quay lại refine spec hoặc test]

10) Checklist 15 phút cho team áp dụng ngay

Checklist SDD nhanh

• Story có mục tiêu business rõ chưa?
• In-scope / out-of-scope đã chốt chưa?
• Có acceptance criteria dạng Given-When-Then chưa?
• Luồng lỗi và edge case đã liệt kê chưa?

Checklist TDD nhanh

• Đã viết test fail cho rule quan trọng nhất chưa?
• Đã chạy vòng Red -> Green -> Refactor chưa?
• Test đang mô tả hành vi hay đang bám chi tiết implementation?
• Đã có test cho case lỗi và case biên chưa?

11) Sai lầm phổ biến cần tránh

12) Kết luận

• TDD tối ưu chất lượng kỹ thuật, tốc độ refactor và độ an toàn thay đổi.
• SDD tối ưu tính đúng đắn nghiệp vụ, sự đồng thuận và quản trị phạm vi.
• Nếu phải chọn cách làm bền vững cho sản phẩm thật: kết hợp SDD + TDD.

Công thức nhớ nhanh:

• SDD trả lời: “Xây cái gì?”
• TDD trả lời: “Xây thế nào để bền?”

Khi hai thứ đi cùng nhau, team vừa đi đúng hướng vừa đi nhanh hơn theo thời gian.

13) Phụ lục: Template mini-spec (copy dùng ngay)

# Mini Spec - <Feature Name>

## 1. Goal
- Business goal:
- User value:

## 2. Scope
- In scope:
- Out of scope:

## 3. Business Rules
- Rule 1:
- Rule 2:

## 4. Acceptance Criteria
- AC1 (Given/When/Then):
- AC2 (Given/When/Then):

## 5. Risks
- Main risks:
- Rollback note:

14) Phụ lục: Template test list (TDD starter)

# TDD Test List - <Feature Name>

## Happy Path
- [ ] Case 1
- [ ] Case 2

## Validation
- [ ] Invalid input 1
- [ ] Invalid input 2

## Error Handling
- [ ] Timeout from dependency
- [ ] Retry/rollback behavior

## Edge Cases
- [ ] Boundary value 1
- [ ] Boundary value 2