🔴 TDD là gì?
Viết test trước, viết code sau.
1
Hiểu nó là gì
TDD yêu cầu viết test cho tính năng chưa có, nhìn nó fail, rồi mới viết vừa đủ code để test pass và dọn lại cho gọn.
Nói theo đời thường:
Như dựng khuôn bánh trước rồi mới đổ bột: khuôn quyết định hình dáng, nên không phải đổ tràn lan rồi ngồi cắt gọt.
Như dựng khuôn bánh trước rồi mới đổ bột: khuôn quyết định hình dáng, nên không phải đổ tràn lan rồi ngồi cắt gọt.
⚠ Chỗ ẩn dụ này hỏng
Dựng khuôn trước rồi đổ bột — hay, nhưng chỉ làm được khi bạn đã biết cái bánh trông thế nào.
TDD hợp với logic đã rõ yêu cầu (tính tiền, kiểm tra dữ liệu). Nó vướng khi bạn đang dò tìm giải pháp, đang thử giao diện, hay đang tích hợp với thứ chưa hiểu rõ. TDD là một công cụ, không phải một tôn giáo — và người bán khoá học hay quên nói vế sau.
2
Code trông thế nào
// 1. Đỏ — viết test cho hàm chưa tồn tại expect(tinhThue(1000)).toBe(100) // 2. Xanh — viết vừa đủ để nó chạy const tinhThue = t => t * 0.1 // 3. Dọn — sửa cho gọn, test vẫn phải xanh
Đỏ → Xanh → Dọn. Vòng lặp chỉ nên mất vài phút mỗi lần.
3
Khi nào bạn dùng nó
✓ Dùng khi
- Logic nghiệp vụ đã rõ yêu cầu
- Nhiều trường hợp biên cần chốt trước
- Đang sửa code cũ và muốn có lưới an toàn
✗ Đừng dùng khi
- Đang thử nghiệm, chưa biết mình muốn gì
- Code giao diện thuần trang trí
Chưa cần biết: TDD ở tầng tích hợp, kiến trúc hexagonal, London vs Chicago school.
Để dành tới Mốc 3 — Tự sửa được khi nó hỏng: Test đỏ trên CI mà xanh ở máy bạn, và bạn biết bắt đầu tìm từ đâu.
Dấu hiệu bạn đã cần học nó: Khi bạn muốn áp TDD cho một hàm gọi 4 dịch vụ bên ngoài và không biết bắt đầu từ đâu.
4
Đi đâu tiếp
- Unit TestLoại test TDD dùng chủ yếu.
- BDDCùng tinh thần nhưng viết ở tầng hành vi, ai cũng đọc được.
- Test CaseBiết viết ca test rõ ràng là điều kiện cần của TDD.