Trong TDD, các thử nghiệm có được viết bởi người thực hiện tính năng đang được kiểm tra không?

Question

Chúng tôi điều hành một dự án mà chúng tôi muốn giải quyết với sự phát triển theo thử nghiệm. Tôi nghĩ về một số câu hỏi nảy sinh khi bắt đầu dự án. Một câu hỏi là: Ai nên viết đơn vị kiểm tra cho một tính năng? Thử nghiệm đơn vị có được viết bởi lập trình viên triển khai tính năng không? Hoặc nên kiểm tra đơn vị được viết bởi một lập trình viên khác, người định nghĩa phương thức nên làm và lập trình viên triển khai tính năng triển khai phương thức cho đến khi chạy thử nghiệm?
Nếu tôi hiểu khái niệm TDD đúng cách, lập trình viên thực hiện tính năng phải tự viết bài kiểm tra, vì TDD là thủ tục với các lần lặp lại nhỏ. Vì vậy, nó sẽ là quá phức tạp để có các bài kiểm tra được viết bởi một lập trình viên?
Bạn sẽ nói gì? Các bài kiểm tra trong TDD có được viết bởi chính lập trình viên hay một lập trình viên khác viết các bài kiểm tra mô tả những gì một phương pháp có thể làm?

Answer 1

Trong TDD, nhà phát triển đầu tiên viết các bài kiểm tra đơn vị không thành công và sau đó sửa mã sản xuất để vượt qua bài kiểm tra. Ý tưởng là các thay đổi được thực hiện theo các bước thực sự nhỏ - vì vậy bạn viết một thử nghiệm gọi một phương thức không tồn tại, sau đó bạn sửa thử nghiệm bằng cách thêm một phương thức trống, sau đó bạn thêm một số xác nhận vào thử nghiệm về phương pháp do đó, nó không thành công một lần nữa, sau đó bạn thực hiện cắt đầu tiên của phương pháp, vv Bởi vì các bước này là quá nhỏ nó không phải là thực tế để có một người riêng biệt viết các bài kiểm tra. Mặt khác, tôi sẽ khuyên bạn nên ghép đôi, để bạn có thêm một số nhãn cầu bổ sung để đảm bảo mã có ý nghĩa.

Tôi nghĩ có thể có một người/nhóm khác hoặc thậm chí là khách hàng (khi bạn sử dụng các công cụ như Thể dục) để viết các bài kiểm tra chấp nhận, kiểm tra toàn bộ chức năng ở cấp độ cao hơn.

Answer 2

Kiểm tra đơn vị phải được viết trước khi mã hóa và kiểm tra xem Đơn vị có đáp ứng các yêu cầu hay không, do đó, nhà phát triển triển khai mã cũng phải viết Bài kiểm tra đơn vị.

Answer 3

Một trong những lợi ích của TDD là chu kỳ phản hồi nhanh. Có một nhà phát triển viết các bài kiểm tra sẽ làm chậm quá trình xuống quá nhiều. Cùng một nhà phát triển nên viết cả hai.

Answer 4

Có thể thực hiện cả hai cách, bạn có thể tự mình viết bài kiểm tra đơn vị, hoặc thực hiện phương pháp ping pong, nơi bạn thay phiên nhau bằng các bài kiểm tra đơn vị viết khác và viết bài thực hiện nếu bạn đang ghép nối. Giải pháp phù hợp là giải pháp phù hợp với bạn và nhóm của bạn. Tôi thích tự mình viết bài kiểm tra, nhưng tôi biết những người khác cũng đã may mắn với phương pháp chơi bóng bàn.

Answer 5

Mỗi câu trả lời của Justin, không chỉ cho nhà phát triển thực hiện viết bài kiểm tra, đó là chuẩn thực tế. Đó là, về mặt lý thuyết, cũng chấp nhận được cho một lập trình viên khác để viết bài kiểm tra. Tôi đã chơi đùa với ý tưởng của một lập trình viên "thử nghiệm" hỗ trợ một nhà phát triển "tính năng", nhưng tôi đã không gặp phải các ví dụ.

Nếu tôi viết một bài kiểm tra cho một đối tượng, ngoài các đầu vào và đầu ra tôi mong đợi, tôi phải biết giao diện nó hiển thị. Nói cách khác, các lớp và phương pháp được kiểm tra phải được quyết định trước khi bắt đầu phát triển. Trong mười hai năm, tôi chỉ có một lần làm việc trong một cửa hàng đạt được mức độ chi tiết của thiết kế đó trước khi bắt đầu phát triển. Tôi không chắc kinh nghiệm của bạn là gì, nhưng dường như nó không phải là rất nhanh nhẹn với tôi.

Answer 6

Tôi nghĩ bạn cần tách riêng Thử nghiệm đơn vị tự động khỏi Phát triển theo hướng thử nghiệm. (IMHO không chỉ là bạn nên tạo nên sự khác biệt quan trọng ở đây).

AUT khuyến nghị mạnh mẽ, TDD yêu cầu kiểm tra phải được viết trước.

TDD tiếp tục làm cho thử nghiệm trở thành một phần thiết yếu của quy trình viết mã. TDD không phải là một phương pháp đảm bảo chất lượng, mà là một cách để suy nghĩ về mã - do đó các trách nhiệm riêng biệt sẽ chống lại triết lý của TDD. Họ cũng sẽ không thực tế - chu trình kiểm tra mới/mã mới rất nhỏ, thường chỉ là vài phút. Theo hiểu biết của tôi, Kiểm tra điều khiển Thiết kế sẽ là mô tả tốt hơn.

AUT có thể được trang bị trên cơ sở mã hiện có (mặc dù thường rất tệ, tùy thuộc vào kích thước và cấu trúc của cơ sở mã). Trách nhiệm riêng biệt có thể có một số lợi thế ở đây. Tuy nhiên, AUT đặt một số áp lực lên thiết kế - vì vậy sự tách biệt sẽ ở mức , loại mã số.

---

Phân biệt: tôi tự do thừa nhận rằng tôi không thích ý tưởng của TDD. Nó có thể hoạt động tốt cho một loại coder nhất định, đối với một số ứng dụng nhất định, trong một số thị trường nhất định - nhưng tất cả các ví dụ, demo và hướng dẫn mà tôi đã thấy cho đến bây giờ làm tôi rùng mình. OTOH, tôi coi AUT là một công cụ có giá trị để đảm bảo chất lượng. Một công cụ có giá trị.

Answer 7

Tôi hơi bối rối ở đây.

Bạn nói rằng bạn muốn sử dụng TDD và bạn có vẻ hiểu nó một cách chính xác rằng một lập trình viên viết một bài kiểm tra, sau đó cùng một lập trình viên viết thực hiện và thực hiện nó trong vài giây/phút tiếp theo sau khi viết bài kiểm tra. Đó là một phần của định nghĩa TDD. (btw 'cùng một lập trình viên' cũng có nghĩa là 'lập trình viên khác trong cặp' khi thực hành lập trình cặp).

Nếu bạn muốn làm điều gì đó khác biệt, hãy tiếp tục và viết kinh nghiệm của mình lên blog hoặc bài viết.

Điều bạn không nên làm là nói rằng những gì bạn làm khác biệt là TDD.

Lý do cho 'cùng một lập trình viên' viết triển khai và viết ngay sau khi thử nghiệm nhằm mục đích phản hồi nhanh, để khám phá cách viết bài kiểm tra tốt, cách thiết kế phần mềm tốt và cách viết triển khai tốt.

Vui lòng xem The Three Rules Of Tdd.

Answer 8

Kiểm tra đơn vị và chấp nhận Thử nghiệm là hai điều khác nhau, cả hai đều có thể (và nên) được thực hiện trong TDD. Bài kiểm tra đơn vị được viết từ quan điểm của nhà phát triển, để đảm bảo rằng mã đang làm những gì cô ấy mong đợi. Kiểm tra chấp nhận được viết từ quan điểm của khách hàng, để đảm bảo mã đáp ứng nhu cầu thích hợp. Nó có thể tạo ra rất nhiều ý nghĩa cho các bài kiểm tra chấp nhận được viết bởi người khác (thường là vì nó đòi hỏi một suy nghĩ hơi khác và kiến ​​thức miền, và bởi vì chúng có thể được thực hiện song song) nhưng bài kiểm tra đơn vị phải được viết bởi nhà phát triển.

TDD cũng nói rằng bạn không nên viết bất kỳ mã nào ngoại trừ để đáp ứng một bài kiểm tra không thành công, vì vậy phải đợi người khác viết Bài kiểm tra đơn vị có vẻ khá kém hiệu quả.