Nếu TDD là về thiết kế tại sao tôi cần nó? [đóng cửa]

Các chuyên gia về TDD ngày càng nói với chúng tôi rằng TDD không phải là về các bài kiểm tra, mà là về thiết kế . Vì vậy, tôi biết một số nhà phát triển tạo ra thiết kế thực sự tuyệt vời mà không cần TDD. Có nên tập TDD không?

TDD không chỉ giúp tôi đi đến thiết kế cuối cùng tốt nhất, nó giúp tôi đạt được điều đó trong ít lần thử hơn.

Tôi đã từng có hai hoặc ba cú đâm vào một vấn đề trước khi quyết định thiết kế nào tôi nghĩ là tốt nhất. Bây giờ, cùng thời gian đó được dành để viết các bài kiểm tra và tập trung tâm trí của tôi vào thiết kế chính xác. Và, như một phần thưởng, nó để lại cho tôi một bộ các bài kiểm tra lặp lại. Thắng lợi!

Điều đó nói rằng, chắc chắn sẽ có những người mà TDD không cung cấp gì. Miễn là họ vẫn có các bài kiểm tra tự động, lặp lại ở cuối bài, điều đó tốt.

Điều mà bậc thầy TDD đặc biệt này thực sự đang cố gắng nói không phải TDD là một quy trình thiết kế (mặc dù một số người đã không may giải thích theo cách đó). Thông điệp ở đây là sử dụng một quy trình như TDD, nếu bạn làm đúng , sẽ có xu hướng cải thiện thiết kế tổng thể của bạn.

Khái niệm cơ bản là một khái niệm cũ hơn nhiều so với TDD; thiết kế để kiểm tra . Nếu bạn tuân thủ nghiêm ngặt các nguyên tắc RẮN , đặc biệt là Nguyên tắc Trách nhiệm duy nhất , bạn sẽ thấy mã rất dễ kiểm tra. Mặt khác, nếu bạn có xu hướng chậm chạp hơn một chút trong thiết kế của mình, có lẽ bạn sẽ tìm thấy quy trình viết bài kiểm tra đơn vị để buộc bạn phải làm điều này thường xuyên hơn, để tránh sự thất vọng của (a) tìm ra những gì cần phải làm được kiểm tra và (b) dành nhiều thời gian hơn để thiết lập các phụ thuộc hơn là viết các bài kiểm tra thực tế.

Bạn không có đi theo TDD để có được những lợi ích của việc này, nhưng nó không giúp đỡ để viết các bài kiểm tra đầu - tốt rất sớm sau khi bạn thực hiện một lớp học, nếu không muốn nói trước hoặc trong. Nếu bạn chờ đợi quá lâu, bạn sẽ gặp rủi ro trong các thử nghiệm "lai bẩn" mà tác giả đang nói đến, nó không có nhiều giá trị vì chúng dễ vỡ và có xu hướng bị phá vỡ trong quá trình tái cấu trúc vô hại - chưa kể đến việc làm lớn hơn -scale thiết kế lại một quá trình cực kỳ khó khăn.

Bạn không thể biết liệu bạn có thực sự thiết kế cho khả năng kiểm tra hay không nếu bạn không viết bài kiểm tra và "kiểm tra tính năng" khó hiểu chỉ với 15% bảo hiểm mã không được tính.

Tất nhiên bạn có thể tạo ra các thiết kế tốt mà không bao giờ viết một bài kiểm tra - nhưng bạn có chắc chúng là những thiết kế tuyệt vời không? Làm thế nào để bạn biết, nếu bạn không xác định rõ ràng bằng các xét nghiệm? Thử nghiệm phát hiện ra rất nhiều vấn đề và trong khi quy trình QA có thể tìm thấy các lỗi có thể nhìn thấy, chúng sẽ không phát hiện ra các quyết định thiết kế kém.

Câu trả lời đơn giản đến từ ai đó đang cố gắng học TDD: Bạn không cần nó, nhưng lợi ích chính mà nó mang lại cho bạn là, khá đơn giản, sự tự tin : Tự tin rằng ứng dụng của bạn hoạt động. Tự tin rằng các trường hợp sử dụng được thỏa mãn. Tự tin rằng logic của bạn là âm thanh cho mô-đun "Foobar". Tự tin rằng mã của bạn được cấu trúc đúng để có thể duy trì và có thể mở rộng sáu tháng sau khi CEO muốn thêm vào một số tính năng điên rồ mới mà anh ta đọc được. Tin tưởng rằng, khi ứng dụng của bạn phát triển, các nền tảng đã được đặt để kiến ​​trúc không bị sụp đổ hoặc đòi hỏi phải có những bản hack lộn xộn cho các tính năng mới của ban giám khảo.

Tôi nhận ra những điều trên nghe có vẻ hơi truyền giáo nhưng đó là cách tôi thấy lợi ích của TDD. Ngay cả khi bạn có thể tạo ra các thiết kế tốt, vững chắc, có kiến ​​trúc tốt bằng cách sử dụng TDD, hãy buộc tay bạn thực hiện đúng, và sau đó chứng minh rằng mọi việc được thực hiện đúng, và quan trọng hơn là cung cấp cơ sở để giữ mọi thứ đúng. Từ rất ít tôi đã học được TDD, sử dụng nó buộc tôi phải làm sạch mã và tuân theo các khái niệm kỹ thuật phần mềm thích hợp, nếu không tôi sẽ làm "điều nhanh nhất có thể" thường dẫn đến mã "hack" lộn xộn.

Tôi chỉ có thể nói từ kinh nghiệm của tôi. Đối với tôi TDD đã mang đến một số thứ tôi chưa từng có trong hộp công cụ thói quen phát triển phong cách của mình. Mặc dù, đáng để nói lại rằng TDD không phải là giải pháp cho mọi thứ. Tôi luôn cố gắng tách riêng thăm dò và thực hiện sản xuất. TDD trong giai đoạn thăm dò là hoàn toàn không cần thiết và thậm chí đang chậm lại. Mặt khác, mã sẵn sàng sản xuất, nó mang lại một số lợi ích mà về ngắn hạn và dài hạn rất có giá trị đối với sức khỏe tinh thần của các nhà phát triển và nghiệp lực của dự án.

• TDD làm cho tôi suy nghĩ trước khi tôi thực hiện, thường là thực hành rất tốt, điều đó ngăn cản nhiều giải pháp bắn và quên
• Nó khiến tôi suy nghĩ theo từng phần nhỏ của vấn đề, buộc tôi phải chia nhỏ giải pháp thành những phần nhỏ khớp với nhau.
• Nó khiến tôi viết mã rất tách rời bởi vì bất cứ khi nào tôi phải bỏ / giả / giả một cái gì đó không phù hợp với vấn đề, tôi tự nhiên ném một "WTF, tại sao tôi phải làm điều này nếu tôi không phải kết hợp với nó" . Và nó làm cho tôi nhận ra kết nối giữa mọi thứ tốt hơn.
• Nó cung cấp cho tôi bộ kiểm tra dễ thực thi cho mã của tôi, vì vậy tôi không phải trải qua kiểu gỡ lỗi mã "var_dump", "p", "pp", "echo". Nó chỉ báo cáo những gì sai, khi nào sai. Và nếu tôi chưa có kiểm tra cho nó, vấn đề chỉ là thêm kiểm tra đơn giản để kiểm tra lại nhiều lần.
• Nó làm cho tôi chắc chắn rằng mã của tôi hoạt động nếu tất cả các thử nghiệm vượt qua trước khi chúng tôi triển khai. Sau đó, thay vì ăn móng tay, tôi đi ăn bánh và uống cà phê và thưởng thức buổi chiều của mình.
• Các bài kiểm tra cấp độ cao là rất tốt trong trường hợp bạn phải cấu trúc lại một cái gì đó. Nếu mô-đun của tôi phải cung cấp một số chức năng cho thế giới bên ngoài và tôi đã phát triển các thử nghiệm chức năng / tích hợp / dưa chuột để chứng minh rằng nó hoạt động chính xác, tôi sẽ rất can đảm để cấu trúc lại mã đó. Một vài lần tôi đã phải đối mặt với mã không có bài kiểm tra và cần phải cấu trúc lại nó. Trong trường hợp đó, có hai cách để đi vào thực tế. 1) bỏ mã 2) bỏ qua các thay đổi và để nguyên như vậy.

Có một điều mà TDD không sửa chữa. Nếu bạn không biết cách xây dựng thứ bạn đang xây dựng, thì TDD sẽ không tạo ra giải pháp cho bạn. Bạn cần có "thiết kế" thô hoặc tổng quan về vấn đề và giải pháp. TDD sẽ khiến bạn chỉ cần thực hiện nó theo cách thanh lịch và dễ bảo trì hơn với mã chất lượng cao hơn.

Cuối cùng, tôi thích suy nghĩ theo thuật ngữ BDD dựa trên thực tiễn TDD. BDD làm cho tôi thực hiện giải pháp bằng cách sử dụng từ vựng của tên miền và để làm cho phần mềm phù hợp với vấn đề tốt hơn.

Có thể có nhiều cách để đạt được thiết kế tuyệt vời, và chắc chắn có nhiều cách hiểu khác nhau về những gì cấu thành "tuyệt vời" - hoặc thậm chí là "tốt". Tôi nghi ngờ hầu hết các TDDers sẽ không đồng ý với bạn về định nghĩa - rằng nếu chúng tôi xem mã bạn cảm thấy là tuyệt vời, chúng tôi sẽ xem xét nó ít hơn tuyệt vời. TDD đưa chúng ta đến một số phẩm chất rất cụ thể và những phẩm chất này hiếm khi được tìm thấy trong mã không TDD.

Khả năng kiểm tra, rõ ràng, là một trong những phẩm chất đó, và là một trong những phẩm chất đó. Các phương thức và lớp cực kỳ nhỏ có lẽ là một đặc tính phụ, và điều này dẫn đến việc đặt tên xuất sắc. Có thể bạn biết các lập trình viên đạt được những phẩm chất này mà không cần làm TDD, nhưng tôi thì không.