Giới thiệu về Phát triển Hướng Kiểm thử (TDD)

Giới thiệu về Phát triển Hướng Kiểm thử (TDD)

Trong một thời gian dài, tôi đã viết các bài kiểm tra theo cách mà hầu hết các nhà phát triển vẫn làm: sau khi viết mã. Tôi sẽ hoàn thành một tính năng, cảm thấy khá hài lòng về nó, sau đó viết các bài kiểm tra để xác nhận nó hoạt động đúng như tôi nghĩ. Các bài kiểm tra luôn vượt qua. Đó là sai lầm đầu tiên của tôi.

Một buổi chiều nọ, tôi tái cấu trúc một hàm tiện ích — dọn dẹp nó, làm cho nó "tốt hơn" — và làm hỏng nó theo một cách mà tôi không nhận ra trong hai ngày. Các bài kiểm tra hiện có đang kiểm tra cách triển khai của tôi, chứ không phải hành vi. Khi tôi thay đổi cách triển khai, các bài kiểm tra cũng thay đổi theo. Không ai phát hiện ra cho đến khi QA.

Đó là lúc tôi thực sự thử TDD. Không phải vì ai đó bảo tôi làm, mà vì tôi đã quá mệt mỏi với kiểu lỗi cụ thể đó.

Chu trình TDD

TDD tuân theo một nhịp điệu ba bước lặp lại. Một khi bạn đã thực hiện nó vài lần, nó sẽ trở thành phản xạ — nhưng vài lần đầu tiên nó có vẻ ngược đời.

Một ví dụ cụ thể: Phép nhân

Ví dụ trong sách giáo khoa nhỏ, nhưng việc thực hiện nó từ từ là đáng giá.

test('multiplies two numbers', () => {
  expect(multiply(3, 4)).toBe(12);
});

function multiply(a, b) {
  return a * b;
}

Đây là cách tái cấu trúc hướng tới sự đúng đắn trông như thế nào khi bạn thêm an toàn kiểu:

11 function multiply(a, b) {
2+  if (typeof a !== 'number' || typeof b !== 'number') {
3+    throw new TypeError('Both arguments must be numbers');
4+  }
25   return a * b;
36 }

Tại sao nó thực sự hiệu quả

Tôi đã hoài nghi về những lợi ích thiết kế cho đến khi tôi thử TDD trên một đoạn mã có yêu cầu không rõ ràng. Việc viết bài kiểm tra trước buộc tôi phải hỏi: thứ này thực sự nên làm gì? Tôi phải định nghĩa giao diện trước khi viết bất kỳ logic nào. Hóa ra đó là câu hỏi khó hơn — và quan trọng hơn.

Bắt đầu từ đâu

Bắt đầu nhỏ. Chọn một hàm tiện ích — một bộ định dạng, một bộ xác thực, một cái gì đó khép kín. Viết bài kiểm tra trước, xem nó thất bại, sau đó làm cho nó vượt qua. Một chu trình. Xem cảm giác thế nào.

Những lợi ích thiết kế không xuất hiện trong một hàm ba dòng. Chúng xuất hiện khi bạn đang xây dựng một cái gì đó có độ phức tạp thực sự và các bài kiểm tra của bạn liên tục cho bạn biết API đang gây nhầm lẫn ở đâu hoặc logic có quá nhiều trách nhiệm ở đâu. Đó là TDD đang làm công việc của nó.

Bạn cũng có thể thích

• Làm chủ kiểm thử E2E với Playwright vào năm 2026
• Hướng dẫn kiểm thử hồi quy hình ảnh và so khớp pixel với Playwright
• Lỗi Hydration trong Next.js: Hướng dẫn đầy đủ về Lỗi #418, #423 & Không khớp nội dung văn bản (2026)
• React trong thực tế: Các mẫu sản xuất, kỷ luật Hook và những cạm bẫy thường gặp