Từ việc đọc các mô tả, tôi hiểu rằng trong các bài kiểm tra TDD được thực hiện trước khi viết chức năng và trong Kiểm tra đơn vị, nó được thực hiện sau đó.
Đây có phải là sự khác biệt chính, hoặc hai thuật ngữ thậm chí không thể được so sánh như vậy. Có lẽ, Kiểm thử đơn vị là một phần tích hợp của TDD.
Câu trả lời:
Đơn vị kiểm tra đề cập đến những gì bạn đang thử nghiệm, TDD để khi bạn đang thử nghiệm.
Hai là trực giao.
Kiểm thử đơn vị có nghĩa là, tốt, kiểm tra các đơn vị hành vi cá nhân. Một đơn vị hành vi riêng lẻ là đơn vị hành vi nhỏ nhất có thể được kiểm tra riêng lẻ. (Tôi biết rằng hai định nghĩa đó là hình tròn, nhưng chúng có vẻ hoạt động khá tốt trong thực tế.)
Bạn có thể viết bài kiểm tra đơn vị trước khi bạn viết mã, sau khi bạn viết mã hoặc trong khi bạn viết mã.
TDD có nghĩa là (một lần nữa, loại rõ ràng) cho phép các bài kiểm tra của bạn thúc đẩy sự phát triển của bạn (và thiết kế của bạn). Bạn có thể làm điều đó với các bài kiểm tra đơn vị, kiểm tra chức năng và kiểm tra chấp nhận. Thông thường, bạn sử dụng cả ba.
Phần quan trọng nhất của TDD là giữa D . Bạn để cho các bài kiểm tra lái bạn. Các bài kiểm tra cho bạn biết phải làm gì, làm gì tiếp theo, khi bạn hoàn thành. Họ cho bạn biết API sẽ là gì, thiết kế là gì. .
Bạn có thể thực hiện kiểm tra đơn vị mà không cần thực hiện phát triển theo hướng kiểm tra. Tuy nhiên, bạn không thể thực hiện phát triển theo hướng kiểm tra mà không sử dụng kiểm tra đơn vị.
Khi bạn thực hiện kiểm tra đơn vị truyền thống , bạn viết kiểm tra sau khi bạn viết mã.
Phương pháp tiếp cận phát triển theo hướng thử nghiệm là viết thử nghiệm đơn vị trước khi viết mã.
Ưu điểm thú vị nhất của TDD (IMHO) so với Kiểm tra đơn vị đơn giản:
TDD và Kiểm thử đơn vị là hai thuật ngữ rất cụ thể thường bị sử dụng sai.
TDD đang viết một bài kiểm tra sẽ thất bại, sau đó viết số lượng mã tối thiểu cần thiết để làm cho nó chạy, sau đó cấu trúc lại mã để làm cho nó sạch. Điều này được thực hiện theo chu kỳ, thất bại -> vượt qua -> tái cấu trúc, thêm một thử nghiệm mới cho mỗi yêu cầu đã biết đối với mã. Gần đây, TDD thậm chí còn trở nên cụ thể hơn về việc viết các bài kiểm tra đơn vị trong chu trình đó, để phân biệt với ATDD (một tập hợp con của BDD) đang viết các bài kiểm tra chấp nhận trong một chu kỳ tương tự.
Kiểm thử đơn vị là về kiểm tra mã trong các đơn vị nhỏ, bị cô lập. Sự nhầm lẫn phổ biến ở đây là nghĩ rằng nếu bạn đang sử dụng một công cụ kiểm tra đơn vị, chẳng hạn như xUnit hoặc Rspec, để chạy các bài kiểm tra mà bạn đang viết bài kiểm tra đơn vị. Điều này không thực sự đúng. Những công cụ đó có thể được sử dụng để chạy các bài kiểm tra nói bằng cách sử dụng khung Selenium - trong trường hợp đó bạn đang viết bài kiểm tra chấp nhận bằng cách sử dụng trình chạy thử đơn vị. Các bài kiểm tra đơn vị là các bài kiểm tra rất cụ thể tập trung vào một đoạn logic nhỏ, tách biệt với mọi thứ khác vì mục đích tốc độ (để bạn có thể chạy chúng thường xuyên và nhận phản hồi nhanh về các lỗi mới).
TDD là cách tiếp cận viết các trường hợp thử nghiệm trước khi phát triển như bạn đã nói và sau đó nhà phát triển viết mã để vượt qua các trường hợp thử nghiệm. Kiểm thử đơn vị là một thuật ngữ được sử dụng để mô tả một loại thử nghiệm phạm vi hẹp khác với thử nghiệm hệ thống, thử nghiệm tích hợp và thử nghiệm chấp nhận.
Cách tôi tách hai người là xem xét rằng TDD ít về thử nghiệm và nhiều hơn về thiết kế mã. Các thử nghiệm đơn vị sau đó được sử dụng để đặt kỳ vọng cho mã kết thúc. Khi mã kết thúc được viết và vượt qua các bài kiểm tra (thông số kỹ thuật), bạn có mã được thiết kế bằng các bài kiểm tra.
Tất cả các câu trả lời tuyệt vời. Tôi sẽ chỉ thêm rằng thử nghiệm đơn vị có xu hướng coi "đơn vị" là một thành phần nhỏ, trong khi TDD mở rộng để bao gồm các thử nghiệm tích hợp và chấp nhận.
(Một số biến thể TDD coi 'đơn vị' là bước tăng nhỏ nhất đối với chức năng mong muốn ...)