Tại sao phát triển theo hướng thử nghiệm bị thiếu trong Thử nghiệm của Joel?

Tôi đã đọc blog này của Joel Spolsky khoảng 12 bước để viết mã tốt hơn . Sự vắng mặt của Test Driven Development thực sự làm tôi ngạc nhiên. Vì vậy, tôi muốn ném câu hỏi cho Gurus. Là TDD không thực sự xứng đáng với nỗ lực?

Phát triển theo hướng thử nghiệm hầu như không được biết đến trước khi cuốn sách của Kent Beck ra mắt vào năm 2002, hai năm sau khi Joel viết bài đăng đó. Câu hỏi sau đó trở thành lý do tại sao Joel không cập nhật bài kiểm tra của mình, hoặc nếu TDD được biết đến nhiều hơn vào năm 2000, liệu anh ta có đưa nó vào tiêu chí của mình không?

Tôi tin rằng anh ta sẽ không có, vì lý do đơn giản rằng điều quan trọng là bạn có một quy trình được xác định rõ ràng, chứ không phải các chi tiết cụ thể của quy trình đó. Đó là lý do tương tự, ông khuyến nghị kiểm soát phiên bản mà không chỉ định hệ thống kiểm soát phiên bản cụ thể hoặc khuyên bạn nên có cơ sở dữ liệu lỗi mà không đề xuất một thương hiệu cụ thể. Các nhóm tốt liên tục cải thiện và thích nghi, và sử dụng các công cụ và quy trình phù hợp với tình huống cụ thể của họ tại thời điểm cụ thể đó. Đối với một số đội, điều đó chắc chắn có nghĩa là TDD. Đối với các đội khác, không quá nhiều. Nếu bạn chấp nhận TDD, hãy chắc chắn rằng nó không nằm ngoài tâm lý sùng bái hàng hóa .

Joel đã thực sự giải quyết điều này cụ thể ở một vài nơi.

Ông giải thích rằng các bài kiểm tra không có khả năng nắm bắt được nhiều vấn đề quan trọng, đặc biệt là những vấn đề chủ quan như "giao diện người dùng của phần mềm này có hút không?" Theo ông, việc phụ thuộc quá nhiều vào các bài kiểm tra tự động tại Microsoft là cách chúng tôi kết thúc với Windows Vista.

Theo kinh nghiệm của anh ấy, anh ấy đã viết như thế nào, các loại lỗi mà người dùng thực sự tìm thấy có xu hướng rơi vào hai loại: 1) loại lỗi xuất hiện trong cách sử dụng phổ biến, mà các lập trình viên sẽ thấy rằng họ tự chạy mã của mình trước khi sử dụng hoặc 2) các trường hợp cạnh khó hiểu đến mức không ai có thể nghĩ sẽ viết các bài kiểm tra để che chúng ngay từ đầu. Anh ta tuyên bố rằng chỉ có một tỷ lệ rất nhỏ các lỗi mà anh ta và nhóm của anh ta sửa trong FogBugz là loại điều mà thử nghiệm đơn vị sẽ mắc phải. (Tôi không thể tìm thấy bài viết đó ngay bây giờ, nhưng nếu có ai biết ý tôi là gì, vui lòng chỉnh sửa liên kết vào đây.)

Và anh ấy đã viết làm thế nào nó có thể rắc rối hơn giá trị của nó, đặc biệt là khi dự án của bạn phát triển thành một dự án rất lớn với nhiều bài kiểm tra đơn vị, và sau đó bạn thay đổi một cái gì đó (cố ý) và kết thúc với một số lượng lớn các bài kiểm tra đơn vị bị hỏng. Anh ta đặc biệt sử dụng các vấn đề mà kiểm tra đơn vị có thể gây ra là lý do tại sao anh ta không thêm nó vào điểm thứ 13 trong Thử nghiệm Joel, ngay cả khi mọi người đề nghị rằng anh ta nên làm.

Joel Spolsky đã trả lời câu hỏi này vào năm 2009 :

Joel: Có một cuộc tranh luận về Phát triển dựa trên thử nghiệm ... bạn có nên thử nghiệm đơn vị cho tất cả mọi thứ, loại công cụ đó ... rất nhiều người viết thư cho tôi, sau khi đọc Thử nghiệm Joel, để nói, "Bạn nên có một ngày 13 điều ở đây: Kiểm tra đơn vị, kiểm tra đơn vị 100% tất cả mã của bạn. "

Và điều đó gây ấn tượng với tôi khi chỉ là một học thuyết hơi quá về một thứ mà bạn có thể không cần. Giống như, toàn bộ ý tưởng về lập trình nhanh không phải là làm những việc trước khi bạn cần, mà là lỗi trang khi cần thiết. Tôi cảm thấy như tự động kiểm tra mọi thứ, rất nhiều lần, sẽ không giúp bạn. Nói cách khác, bạn sẽ viết rất nhiều bài kiểm tra đơn vị để đảm bảo rằng mã đó thực sự sẽ hoạt động và bạn chắc chắn sẽ tìm hiểu xem nó có hoạt động không [nếu bạn không viết các bài kiểm tra], thực tế vẫn còn hoạt động, ... Tôi không biết, tôi sẽ nhận được thư lửa như vậy vì tôi không thể hiện nó tốt. Nhưng, tôi cảm thấy nếu một đội thực sự có phạm vi bảo hiểm 100% mã cho các bài kiểm tra đơn vị của họ, sẽ có một vài vấn đề. Một, họ đã dành rất nhiều thời gian để viết bài kiểm tra đơn vị, và họ không nhất thiết có thể trả tiền cho thời gian đó với chất lượng được cải thiện. Ý tôi là, họ có một số chất lượng được cải thiện và họ có khả năng thay đổi mọi thứ trong mã của họ với sự tự tin rằng họ không phá vỡ bất cứ điều gì, nhưng đó là điều đó.

Nhưng vấn đề thực sự với các bài kiểm tra đơn vị như tôi đã khám phá là loại thay đổi mà bạn có xu hướng thực hiện khi mã phát triển có xu hướng phá vỡ một tỷ lệ phần trăm không đổi trong các bài kiểm tra đơn vị của bạn. Đôi khi bạn sẽ thực hiện thay đổi mã của mình, bằng cách nào đó, phá vỡ 10% bài kiểm tra đơn vị của bạn. Cố ý. Bởi vì bạn đã thay đổi thiết kế của một cái gì đó ... bạn đã chuyển một menu, và bây giờ mọi thứ dựa trên menu đó đang ở đó ... menu bây giờ ở nơi khác. Và vì vậy tất cả những bài kiểm tra bây giờ phá vỡ. Và bạn phải có khả năng đi vào và tạo lại các thử nghiệm đó để phản ánh thực tế mới của mã.

Vì vậy, kết quả cuối cùng là, khi dự án của bạn ngày càng lớn hơn, nếu bạn thực sự có nhiều bài kiểm tra đơn vị, số tiền đầu tư bạn sẽ phải thực hiện để duy trì các bài kiểm tra đơn vị đó, giữ cho chúng cập nhật và giữ họ đi qua, bắt đầu trở nên không cân xứng với số tiền mà bạn nhận được từ họ.

Không ai ngoài Joel có thể trả lời chắc chắn. Nhưng chúng ta có thể thử một số lý do / quan sát.

Trước hết, thử nghiệm không vắng mặt trong Thử nghiệm của Joel

• Các xét nghiệm được đề cập hai lần trong 12 bước trực tiếp (10 và 12)
• Sự tồn tại của một bản dựng là một trong những điểm đầu tiên. Ý tưởng của việc xây dựng là để có được khả năng xem liệu chúng có bị hỏng hay không, vì vậy chúng tôi (cũng) đang nói về việc thử nghiệm ở đây.

Thứ hai, toàn bộ ý tưởng của Thử nghiệm Joel (theo tôi hiểu) là có câu hỏi nhanh, có - không. "Bạn có làm TDD không?" sẽ không chính xác phù hợp (câu trả lời có thể là: "một số người trong chúng tôi", "cho phần đó của mã" hoặc "chúng tôi thực hiện kiểm tra đơn vị".

Thứ ba, tôi nghĩ không ai nói rằng (kể cả Joel) rằng những điểm mà "người duy nhất đáng giá thời gian" (nhân tiện, "bạn có lập trình" không ở trên đó không), chỉ là đó là những câu hỏi nhanh để hỏi khi đến tiếp xúc với một nhóm phần mềm, dù là thành viên nhóm tương lai hay thậm chí là khách hàng - đây là danh sách tôi đã đưa cho một số người không có kỹ thuật xung quanh tôi đang tìm kiếm manh mối về việc bộ phận CNTT của họ tốt / xấu như thế nào. Nó không phải là tất cả, nhưng nó thực sự tồi tệ để đánh bại trong ba phút.